前端与全栈开发随笔：少背路线图，多写能跑的软件

学 Web 开发最容易掉进的一个坑，就是把精力全花在“收藏学习路线图”和“跟进新框架发布”上。今天看别人聊状态管理，明天看构建器性能对比，收藏夹塞得满满当当，真要自己从零搭个顺手的小应用，却连个表单校验和错位布局都调不利索。

回头看这几年的折腾，真正让我写代码变笃定的，往往不是又追了哪个新轮子，而是被实际项目毒打之后攒下来的那点直觉。

框架兜不住原生机制的盲区

很多人觉得现在都是组件化开发了，只管写状态和模板就行，DOM、事件流、层叠上下文这些老黄历不用深究。

平时写普通业务页确实能混过去，但一旦遇到诡异的线上 bug，基础盲区就会立刻现形：

• 给卡片加了个 transform: rotate(-1deg)，为什么原本 z-index: -1 的伪元素背景突然跑到文字上面去了？（因为 transform 创建了新的层叠上下文。）
• 列表滚动卡顿，到底是重绘范围太大，还是滚动监听忘了加 { passive: true } 阻塞了合成线程？
• 页面偶发白屏或布局跳动，是字体加载策略没配好，还是异步请求竞态把旧数据盖到了新视图上？

这些问题查框架文档是查不到答案的。框架只是帮我们省掉了手动拼 DOM 的体力活，并没有接管浏览器的渲染管线和网络协议。 把 HTML 语义、CSS 盒模型与层叠规则、浏览器事件循环和 HTTP 缓存头摸透，换什么框架都只是换套语法方言。

带着真实痛点去写，别在 Demo 里打转

跟着教程敲十个 TodoList，不如自己动手写一个哪怕很丑、但自己天天要用的工具。

教程里的环境总是温室：接口永远正常返回、数据永远干净、需求永远不会中途拐弯。可一旦你自己做个东西——哪怕只是给机器人插件写个配置面板，或者给自己搭个带多套主题切换的静态博客——现实问题就会排着队找上门：

• 接口超时或者上游限流了，界面怎么给反馈才不会让用户以为卡死了？
• 用户开了深色模式或者系统的“减弱动态效果”（prefers-reduced-motion），样式和动画怎么降级？
• 构建脚本挂在 CI 上，怎么在不引一堆重型依赖的前提下保证每次产物一致？

为了解决这些具体卡点去翻 MDN、读源码、看 DevTools 的 Performance 和 Network 面板，记下来的东西才是真正长在脑子里的。

先学会做减法

刚上手全栈开发那会儿，我也喜欢把技术栈铺得很满：前端必上全家桶，样式必配原子化方案，后端哪怕只有两个转发接口也要套一层厚重的目录结构。写的时候觉得特正规，过三个月回来改一行小逻辑，光启动本地环境就要折腾半天。

现在我开新项目的习惯完全反过来了：先问自己，不引这个库能不能写？

• 只是做个几页的静态站点，原生 CSS 变量（Custom Properties）配合语义化标签就能把主题切换和响应式管得明明白白，没必要先装一套 UI 框架。
• 只是做个轻量级的 API 代理或流式转发服务，用 Deno 或原生 Node.js 的 Web Fetch API 几百行就能跑得很稳，不必上来就搭复杂的微服务架子。
• 只有当手写代码开始出现明显的重复、状态散落到难以追踪时，再去引入对应的抽象和工具。

几个受用至今的小习惯

如果非要总结几条日常开发里最管用的习惯，大概就这几件：

1. 把浏览器 DevTools 当成主战场：遇到样式不生效先看 Computed 和层叠关系，遇到接口慢先看 Waterfall，别靠在代码里盲猜加 !important 或 setTimeout。
2. 给自己的项目写自动化自检：不管是类型检查、简单的断言脚本还是样式合规扫描，能交给机器拦住的低级错误，就别靠人眼去盯。
3. 隔段时间回头改改自己的旧代码：半年前写的模块现在看着觉得哪里别扭、哪里耦合太死，动手重构一遍，比看十篇“架构最佳实践”感触都深。

Web 技术圈的热点永远追不完，但好软件的标准一直没怎么变过：结构清晰、边界干净、出了问题好排查、隔半年再打开还能改得动。守住这几条，心里就不容易慌。