前言
前端 UI 一直是多变且复杂的题材，经历各种工具迭代与起伏，像是：
- 早期浏览器标准混乱到稳定
- 没有完善的测试工具到如今丰富的测试生态系
- CSS 管理方法论转变（BEM、OOCSS…… -> Utility First）
- 早期 jQuery 指令式操作 DOM 转向 React Vue 等现代声明式组件框架
- Pre-styled 样式库（Chakra、AntD、Bootstrap）到 Headless （zag、React Aria、Radix UI）框架盛行
经历过太多的跌宕变化，这篇文章记录我认为现阶段可以怎么打造高效率可维护的前端。
坑点一：在不稳定的基础上建立测试
打造自制的 UI 看似简单，实际要处理的边界情况（如浏览器差异、无障碍 a11y、键盘操作）极为复杂。
大多数时候甚至不需要去制作已经烂大街的 UI ，很多界面看起来很简单但实际维护起来却是地狱，浏览器差异、版本问题、复杂的环境有太多的变因在网页环境当中，举例：Radix 一个看似简单的 Dropdown Menu 就耗费数月上千个 commit 来完善。
建立测试需要花费代价，自动化测试应专注于产生价值的代码：“业务逻辑是否行为正确且可被自动验证？”
坑点二：速度与信心的两难
网页执行于浏览器环境中，自然要模拟浏览器进行测试，这也是传统 E2E 测试方案如 Cypress 与 Playwright的强项，而另一方向是透过模拟浏览器环境与 API 如 jsdom 来达成在 Node.js 环境模拟测试网页的目的。
- 模拟真实浏览器永远太慢太贵。
- 模拟假的浏览器环境又存在许多与真实浏览器偏移的问题。
- 我无法表达光是一个轻微的 jsdom 模拟浏览器上的实践差异就可能造成数小时的 Debug 有多恼人，很多奇怪的问题真的会需要参考成熟的大型项目如 Reka UI 的测试代码才知道哪些变通方案是必须的。
这也是为什么 Cypress Component Testing、Playwright Components 与 Vitest Browser Mode会出现，为了在现代网页测试的“速度”与“信心”之间找到一个更优的平衡点，这些技术目前都还在实验路上。了解测试目的与工具的差异并做出取舍。
坑点三：被遗忘的测试
很多项目写了测试，但因为太慢、太不稳定（Flaky），导致：
- 错误的测试：一个不稳定测试对团队信心的打击，比没有测试还严重。
- 测试只在被执行时才有价值：上一份工作的测试心得总结 为什么要替软件进行测试？
- 反馈速度： 让测试能快速运行，开发者才愿意在开发中频繁执行它。