技能介绍

前端“能用”和“能用好”之间的差距

这个技能要解决的问题很具体：实现 UI 组件、页面布局或响应式设计时，把“跑通了”当成完成，然后带着一套自洽的借口交付——框架会处理响应式、用户网速都很快、无障碍是设计稿的事、现代浏览器全都支持。结果是 60%+ 的移动端流量拿到一份桌面优先的页面，53% 的用户在等待 3 秒后离开。技能把这类自我说服整理成一张对照表，每条借口都对应一个明确的纠正动作，而不是一句空洞的原则。

五条不可协商的强制项

核心机制是一条“Iron Law”：没有无障碍、响应式和性能的前端代码不允许上线，没有例外。具体拆成五个模块：

响应式设计：移动端优先，断点覆盖 320px、576px、768px、992px、1200px，触摸目标不小于 44x44px，任何断点都不出现横向滚动，并且在真机上验证而非只看浏览器开发者工具。
性能优化：从第一天就设性能预算——FCP < 1.5s、LCP < 2.5s、CLS < 0.1、首屏 bundle < 200KB，图片优化并懒加载，配合代码分割。
无障碍实现：语义化 HTML、键盘导航、可见的 focus 指示、WCAG AA 对比度、表单 label 与错误信息、图片 alt、skip navigation。关键立场是：设计稿不算实现，代码才算。
浏览器兼容：在 .browserslistrc 里声明目标浏览器并真正测试，新特性走渐进增强，旧环境用 polyfill 和 CSS fallback。
代码质量：组件化架构、单一职责、错误处理、有意义的命名、复杂逻辑注释写 WHY 不写 WHAT、lint 通过、无冗余代码与依赖、TypeScript 或 JSDoc 类型覆盖。

每个模块都配了一张红线检查表，提交前逐条勾选，缺一项即视为未完成，需要回退重做。

适用边界与注意点

这份清单的强度是刻意的，但落地需要几样配套工具：browserslist 配置、linter、Lighthouse 之类的度量工具，否则大量条目只能靠人工判断。它不提供组件库或设计系统，只约束实现质量，实际的组件结构仍需自行定义。另外，“真机测试”和“性能预算”这类要求，对一次性原型或纯内部工具可能过重，更适合面向不可控用户的交付物。判断标准很简单：这段代码会不会被真实用户在未知设备和网络下打开——会，就按清单执行。