七月技术栈复盘：对的决策、要重构的节点与八月路线

七月技术栈复盘对的决策、要重构的节点与八月路线一、月末的技术债盘点时刻七月的最后一天。对于独立开发者这是一个值得停下来做「技术栈复盘」的时间点——不是泛泛地想「我的技术选型还行不行」而是具体地盘点哪些选型决策被过去一个月的使用数据验证是对的哪些开始暴露瓶颈需要重构以及八月的架构演进应该把精力投在哪里。这篇文章将以「独立开发者」的第一人称视角复盘七月技术栈演进中的四个关键决策节点并给出八月的演进路线。这不是一篇「技术选型指南」而是一篇「基于真实使用数据的决策复盘」。二、对的决策被七月使用数据验证的三个选型过去 30 天产品从「能跑」走到了「有稳定用户在使用」的阶段。这个过程中有三个技术选型决策被数据验证是对的。决策一前端用 Astro且坚持「静态优先、岛屿按需」的策略。七月第三周产品达到了「单日 3000 次页面访问」的节点。在没做任何专项性能优化的前提下Lighthouse 性能评分稳定在 92-97 分之间。核心原因是Astro 的「静态优先」策略让 90% 的页面内容在构建时就生成了纯静态 HTMLCDN 边缘节点可以直接返回不需要服务端渲染「岛屿按需」策略让交互组件如点赞按钮、订阅表单的客户端 JavaScript 总体积控制在 12KB 以内。如果七月选的是「全 SPA CSR」的方案在 3000 次/日的访问量下性能评分大概率会掉到 70 分以下因为所有页面都需要客户端渲染且 JS Bundle 体积会大得多。这个决策对的验证数据是 Lighthouse 评分和 WebPageTest 的实际加载瀑布流。决策二数据库用 PostgreSQL且在一开始就做了「读写分离」的预留设计。七月第二周产品的写入 QPS 达到了 SQLite 的上限边界约 80 QPS 的峰值写入。如果一开始选的是 SQLite 且没有留迁移路径这时候会面临「必须立即迁移但迁移方案还没验证」的被动局面。但因为在一开始设计数据访问层时就留了「读写分离」的接口抽象读操作可以指向只读副本写操作指向主库实际扩容时只需要在数据访问层中修改「读操作的连接池指向」而不需要改业务逻辑代码。这个决策对的验证数据是在写入 QPS 从 30 涨到 120 的过程中产品没有出现任何数据库层面的可用性下降。决策三部署用「Vercel Render」的组合而不是「全 VPS 自建」。七月产品经历了两次「意外流量」事件一次被 Twitter 上的某个账号推荐一次被 Product Hunt 的周榜推荐。在推荐发生的 2-3 小时内流量分别是平时的 15 倍和 27 倍。如果部署方案是「单台 VPS」这两次事件大概率会导致服务不可用VPS 的 CPU 和带宽都会被打满。但因为用的是「Vercel前端自动扩缩容 Render后端支持按请求量的自动扩容」的组合两次事件都没有导致服务不可用——平台自动处理了流量峰值。这个决策对的验证数据是「两次流量峰值事件中的可用性100%」。三、要重构的节点开始暴露瓶颈的三个地方对的决策之外七月也暴露了三个「当初做得不够、现在开始拖慢迭代速度」的技术债。这些是八月需要优先重构的节点。节点一后端代码的「模块边界模糊」。七月中期在加一个「用户通知偏好管理」的功能时发现需要同时改UserController、NotificationService、EmailService三个模块的代码且这三个模块的代码耦合度已经高到「改一个地方另外两个地方的逻辑也需要跟着调」的程度。这个瓶颈的根源是产品初期五六月为了「快速验证」把部分业务逻辑直接写在了 Controller 层而没有抽离到独立的 Service 层。现在模块多了这种「职责不清晰」的设计开始拖慢功能开发速度。重构优先级的判断高。因为模块边界模糊已经在拖慢新功能的开发速度且越往后拖重构成本越高因为耦合的模块会越来越多。节点二前端状态管理的「颗粒度不够」。七月后期在产品加了一个「实时协作编辑基于 WebSocket」的功能后发现前端的全局状态管理用 Zustand 做的开始出现「状态更新颗粒度不够」的问题——某个用户的光标位置变化会导致所有在线用户的界面都重新渲染。这个瓶颈的根源是 Zustand 的 Store 设计得不够细粒度——把「在线用户列表」、「光标位置」、「文档内容」都放在了一个 Store 里。需要重构为「按领域拆 Store」且用 Selector 做细粒度订阅。重构优先级的判断中。因为实时协作功能的用户渗透率还不高约 12% 的日活用户使用所以这个问题目前对大多数用户没有影响。但八月准备在实时协作上加大投入所以需要在八月早期就把这个重构做了。节点三CI/CD 流水线的「构建时间过长」。七月后期产品的代码量增长到了「前端 后端共约 3.5 万行」的规模。这时npm installvite builddocker build的 CI 流程在 GitHub Actions 的标准 runner 上需要约 8-11 分钟才能完成。这个瓶颈本身不影响产品可用性但影响「迭代心流」——改了一行代码要等 11 分钟才能知道是否构建成功。且如果构建失败了修复后需要再等 11 分钟。重构优先级的判断中高。可以接受但「等待构建」的心流中断在长期会累积成「迭代速度隐性下降」。八月的优化方向是引入构建缓存用 Turbo 的 Remote Cache、以及把前后端构建拆成并行任务。四、八月路线架构演进的优先级判断框架基于对的和需要重构的节点的盘点八月的架构演进路线图可以用一个简单的「投入 - 收益」框架来判断优先级。优先级 1模块边界重构。投入中等预计 3-4 个工作日但收益高——重构完成后新功能的开发速度会明显提升。计划在八月第一周完成。优先级 2CI/CD 构建优化。投入低引入构建缓存 并行化预计 1-2 个工作日但收益中等偏高——构建时间从 11 分钟降到 3 分钟以内对迭代心流的改善是实质的。计划在八月第二周完成。优先级 3前端状态管理重构。投入中等预计 2-3 个工作日收益中等——为实时协作功能的深化打基础。计划在八月第三周完成。优先级 4 和 5E2E 测试和数据库扩容。这两个任务重要但八月的用户规模增长预期还不至于让它们成为瓶颈可以延后到九月再做。五、总结七月末的技术栈复盘核心结论可以归纳为一句话对的决策是在产品规模增长时不需要「推翻重来」的决策需要重构的节点是在产品规模增长时开始「拖慢迭代速度」的地方。被七月数据验证对的三个决策Astro 的静态优先策略性能评分稳定在 92、PostgreSQL 的读写分离预留设计流量峰值时可用性 100%、以及 Vercel Render 的托管组合自动扩缩容应对意外流量。这三个决策的共同点是它们在产品初期看起来「可能过度设计」但在规模增长时证明了「刚好够用且有演进空间」。需要八月优先重构的三个节点后端模块边界模糊高优先级第一周做、前端状态管理颗粒度不够中优先级第三周做、以及 CI/CD 构建时间过长中高优先级第二周做。八月架构演进的路线应该由「重构收益」驱动而不是由「追逐新技术」驱动。好的技术栈演进是让架构复杂度始终「刚好领先于」产品规模半个身位——不那么少也不那么多。资料说明本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论不应视为行业事实。可参考 0731 资料来源索引并在发布前将具体来源贴到对应断言之后。