文档
个人网站成长记（技术栈篇）
前言
最近半年，在思考，在探索，想找到一条属于自己的谋生之路，与其想破天，不如先行动起来。
为了谋生，但也不能过于谋生，多少还需要点儿理想主义。
也许将技术、写作和可交互结合起来是一个出路。
上一版
起初，尝试 Nextjs 和antd构造前端的页面。但在经过两个月的开发后，网站已经初步成型（地址是）。 虽然大的功能模块进本成型了，也能读取md(x)文档可视化，可交互了，但总觉得还是缺了些什么。 经过一些思考后，想来有下面几种原因。最重要的一点是缺少想象力，有很多东西也只能想个大概，不知道如何合理的展示给用户；其次缺少细节，但还有机会在优化；再次，网站的企业味道太浓厚了，像是个全副武装的重步兵，给人一种笨重的感觉，所有的东西都中规中矩，缺少了灵动性，不太适合作为个人的品牌。
设计上也踩了些不少的坑，比如说喜欢的SPA固定屏幕，所有的元素都在内部滚动，这种设计在大屏上没什么问题，能够展示足够多的信息，但是实现响应式后，在手机上小屏幕上就是个灾难，重要的信息只能够狭小的空间里滚动，几乎无法阅读。
在架构上，依靠惯性，单独的搭建了一套Nodejs后台系统，用于管理文档，同步数据，解析notion文档等后台工作，但在单独维护一套后端系统，也要花费时间和精力想想其实也是没有必要的。
新的尝试
偶然的机会，接触到了Remix，Shadcn，Tailwind等等技术，在尝试做了一个demo网页后，被这种简洁的写法打动了，太轻盈灵活了。 shadcn既能简单快速的复用封装的逻辑功能，又能结合tailwind随时定制样式，可太方便了。同时Remix的配置式的路由也简化了nextjs的文件结构…
更换技术架构一切从头开始，对所有的项目来说都是一个挑战。以前付出的沉没成本，创造出的价值都归零了，但对于个人项目来说，我可以做主。在一番短暂的纠结后（好在没有在这上面花费太多的时间），开始了解新的技术验证。
技术选择上优先选择能够简化开发的技术，尽可能的在云端实现，这样就能减少本地环境的维护，CI/CD也尽可能使用云上的方法。
轻度尝试了下Firebase，Backend as a service， 非常心动，能简化不少工作量，可是国内访问不友好，不得不放弃。
数据库还是使用MongoDB，只不过从本地的docker，替换到MongoDB Altas上，不用配置dockerFile，不用顾虑迁移问题，只需要一个连接字符串即可，简直太方便了，为什么没有早点儿发现。免费额度对于个人来说应该是够用了。
之前使用的是原生的数据库连接，自己封装连接组件进行数据库操作。后来顺着MongoDB Altas摸到了Prisma，用于简化数据库连接和操作，必须要尝试下。
Vercel直接从GitHub fetch代码，开发部署一条龙， 一个git push 稍等一会儿就可以看效果了，必须安排上。从不同的branch对应开发，测试，产品环境，简直不要太香。
顺着Vercel，自然摸到了v0.dev，UI设计代码自动生成，再也不用纠结该怎么设计页面布局了，用好提示词，简直就是个贴心小棉袄。
甚至还有github codebase，连本地的开发环境都不用搭建了，一切都在云端，不要太贴心了， 想配置台性能略高的计算机的心都碎了。
就在写这篇文章的前一个小时，从小红书上刷到了Convex，一个全栈的JS框架，保持好奇心就够了，实在没精力在折腾了。
一句题外话，一个开放的环境才有创新的土壤，才能使想法的种子萌芽出来。真的应该感谢开源，感谢共享。好消息是程序员总能专注于开发本身了，但坏消息是程序员要失业了
持续的开发
转眼间，又是一个多月过去了，想起来好像没干太多的事情，但写起来却又发现似乎做了很多的事情。功能上也只是部分的迁移到了新的站点，后台管理系统也融合进来了。网站也已迭代的方式上线了，并且购买了域名，完成了备案和解析，算是正式上线了。目前的这套技术栈已经不需要ECS了。只需要一个域名转跳到vercel地址就好了，可惜了我前期花费数个工作日踩坑阿里云ECS 2GB内存build不出来的坑了，最后绕道github action填坑的故事了。
当前的一些进展
为了融合前后端，不得不实现权鉴，否则谁都可以更改我网站的内容那不全乱套了么，所以自然有登录，有了登录还有登出/注册等等。所以得有session management，将授权后的用户信息加密成后存在cookie里面，在进行敏感操作时解密cookie校验用户信息，一个authorization就完成了，听起来挺简单的。
网站主要以博客为主，总不可能不能写作，每次用外部工具导入markdown文档把，这样做也太不极客了把， 一个偶然的机会，发现了tiptap，居然能够实现类似notion的 slash command，心动的感觉一定要集成进来。可是集成起来，才发现这里面有多少细节要处理了，现在也才处于一个勉强可用的状态，这篇文章就是在这里面敲出来了，但因为编辑器的缘故被多次打断。 所以一个好用的编辑器对文字工作者不亚于程序员的VSCode。但明明有现成好用的工具，为什么我还要自己DIY呢，这是个好问题，我也在怀疑，但这也是DIY的乐趣所在把，没有KPI的束缚，我可以自由自由的玩耍。
对了之前一直在纠结博客图片资源存储问题也得到了解决，随着vercel发布新的Blob Store，可以通过简单的API来上传和展示图片，目前也已经集成进了写博客的文档编辑器，目前来说免费的资源还够用。 但如果哪一天提供的资源不够用了，我想我会乐意付费的。
TypeScript是现代前端开发绕不过去的话题了，但这个东西对于老鸟来说确实太不友好了，限制太多，也束缚了太多的自由。目前开发中很大一部分精力都在和type较劲，对于不需要合作的个人项目可能也不是必要的。但正因为限制多多，也减少了交流沟通的成本，对计算机和合作者来说都是。
最开始权鉴的时候还是用react-hook-form和zod等等来强制校验表单的提交，对于习惯于自由自在书法javascript的程序员来说，也不是那么容易。往往因为一个类型推断错误，而不得不耗费大量的时间。
配合着tailwind css 书写样式不要太轻松了，虽然刚开始熟悉的时候每个原子样式都要去查文档，但写多了后效率的提升还是很明显的。 在上一个版本中，书写样式是见相对复杂的事情，即便已经简化了许多，我需要先createStyle定义一些class，在使用useStyle的hook引入，最后在元素的className中配置class，往往一个jsx或者tsx文档中包含大量的这种胶水代码。除非不得不，否则我是不想给我的html标签加上样式的。
目前使用的是十一月发布的Next15和react19，个人项目比企业项目灵活是因为历史包袱小，试错成本低，可以像个粉丝一样追着最新的技术和最佳实践。前面的版本就是因为在升级过程中，对在react19中废弃的forwardRef的使用一直报错而萌生的重构的念头。
后面的工作依然还有很多
优化和SEO
昨晚，在google search console中发现我的网站还没有被收录和索引，显然是有些工作还没有做好。并且网站的内容也还太少，所以就从这篇文章开始丰满网站的内容把。个人的敏捷实践确实可以这么随性。SEO在等等，看search console给的建议在优化，对于网站性能的优化现在顾虑不上，得先把功能都实现完再说。
Markdown的解析
这部分工作在上一个版本中已经实现，但是对于UI的控制还是没有那么精细，还需要制定更多的细节。
从Notion 导出markdown文档，然后去除掉生成的md5信息，图片资源的relocate，链接的修复等等代码都已经实现了，迁移到新的系统就好。
下一步将md文档通过next-mdx-remote加载进来，配置好将md转换成AST的remark插件，以及将AST转换成HTML的rehype插件后，在自定义成shadcn的ecomponent后因该就能正确的展示出来了，这些技术路径都是现成的，应该花费不了太多的时间。
唯一的问题是需要定义文档树结构的组件，暂时没找到现成的shadcn组件，这一部分也许要自己实现，或者不得不在引入第三方的工具。
Design上的思考
对于目前网页展示的内容和布局排列方式，甚至是首页内容，都还需要在思考，在迭代。如何把重要的信息以自然的方式展示在重要的位置，可能也需要补一补设计的课程了
还有些功能上的实现不涉及技术方面，目前也还在持续的思考中。
对技术的思考
前几年记得某项技术刚出来的时候，有人在其github issue里留言说别更新了学不动了，一时笑谈。
确实新的技术发展太快了，就前端来说，各种各样的框架层出不穷，从最早的JSP，Jquery，后来的AngularJ,Vue,React三分天下。到现在向NextJs Remix等，build 工具从grunt，babel，webpack到vite等等从css到sass，scss到css module到css in js 到tailwind等等。
大概六七年前，我曾想如何把前端和后端集成在一个项目里，但也只能是皮骨分离，似是而非。费功夫写出来的webpack脚本，在几个月后就跑不起来了，可能现在还在github仓库里面。想想那会要自己配置解析svg各种各样的plugin各种各样的loader，甚至还要管理build的过程，比如在build前删掉老的build，把对应的build结果打包拷贝到对应的地方。更早就是写出来的JSP需要打一个Jar包，把Jar包部署到服务器的某个目录下面去。 过去的这些事都是很有时代感的东西。
每个新的框架出来，都是为了解决特定的问题。技术永远是为了让生活变得更美好，这是技术发展的原动力。现在的框架屏蔽了太多的底层细节，能够让开发者专注于业务本身，降低了技术的使用门槛。无需关心路由的配置，build的控制，js本身版本的转码，甚至服务端和客户端的区分都没那么明显了，一个component里面不仅能操作数据库还能更新UI，初次见到这种写法的时候，震惊之余还在调侃，可后面越用越香。 但如果没有框架来处理里面的细节，这样的代码可就异想天开，贻笑大方了。
但也无需恐惧新技术，一路走来，有的技术已经不用了，有的却还在进化中，但是万变不离其宗，好的思想好的方法，会一路传承下去。但如果对某一项了解的比较深入的话，对新的东西永远会惊喜连连，哇还可以这样做，为什么自己以前都没想到，或者想到了没能去实践。
不要畏惧新的技术，持续的学习，永远的好奇是一个程序员永不过时的核心能力。
对AI的思考
AI有时候让我很恐慌，有时候又觉得它不过尔尔。但以发展的眼光来看，还是应该恐慌的。
在生活工作中已经离不开AI了，很多的事情，我都会去先问问AI，如果解决不了，我会在去搜素引擎查询。如果AI替代了搜索引擎的作用，那么我做这个网站的意义又在哪儿呢？难道真的只是为了记录吗，那么没有反馈的坚持注定是无法持续的。
AI对职业的替代让我对前端开发也很担忧，坦诚的说，这个站点的设计和部分动画都是参考了 v0 给的实现, 确实极大的加快了我的开发进程，但是在处理细节和bug修复上还差点儿意思，也可能我免费账户因为token有限没法精细的引导v0去修复，无法展示出v0真实的能力。
v0这个名字起的相当的贴切，能按预期帮你快速的搭建出项目做出第零个版本，但我觉得这实际上不是AI的能力，而是automation的能力。 不知道在复杂项目下比如几千万行代码以上的复杂系统中AI的能力究竟如何，凭我的想象，如果系统的复杂程度上升，那么定位和对细节的把握难度将会成指数的上升。就如同在十个人中找到一个人和在地球上找到一个人完全不是一个难度的事情。而AI是否能应对指数级复杂度的增长，而不在概率云中乱撞，这样的能力或许仍需要验证。
但是拥抱AI才是目前的出路，逃避AI对人类对个人的影响才是自欺欺人。