评审关注接口而非实现细节
别名: 接口评审 · 公共契约评审 · public contract review · 不审样式表
概念解释
组件一旦被调用，使用方绑住的是它对外承诺的那一层：属性、插槽、可观察状态、无障碍角色、允许读取的语义别名。样式表里的类名、内部钩子、内边距的偶然取值，使用方不该依赖，作者也应能改。接口优先的评审（API-first review）把评论对准这张公共契约，而不是对准一次截图里的像素或一次实现里的选择器。审实现细节，贡献者会学会把快乐路径画漂亮；审接口，贡献者才知道哪一张表被冻结、哪一层下周还能动。
实现可以在契约内部换；契约改了，所有调用点一起改。
机制
耦合沿着被依赖的名字走。评审若把精力花在「这段 CSS 能不能再短」「这个圆角是不是 8」上，冻结的是明天就该可替换的内部。真正昂贵的错误是：属性语义含糊（type 同时表示视觉和 HTML）、插槽在某种变体下被吞掉、键盘与屏幕阅读器的行为未写进契约、主题切换时哪些别名保证还在。这些不会出现在一张静态图里。把评审对象换成接口表——每个输入的含义、默认、非法组合、每个输出和事件、每种状态下的名称/角色/状态——评论才打在使用方会碰到的面上。内部选择器的洁癖可以留给作者或后续重构，不在准入时挡路，也不在准入时被当成质量的代理指标。
边界
无障碍与安全有时就是实现：焦点是否困在对话框里、是否用原生按钮而不是可点击的 div，这些看起来像内部，实际是契约的一部分，因为辅助技术和浏览器只认那一层。性能预算若写明「不得在渲染路径读布局」，实现选择也进入评审。视觉回归作为补充检查可以抓住无意走样，但不能替代接口表——像素一致、属性却无法预测的组件，调用方仍然会用错。一对一的内部工具、不对外发布的草稿件，可以只看效果；一旦声明「可被其他仓库引用」，评审切到契约。
怎么落地
- 贡献包必须带一张接口表：属性、插槽、事件、无障碍承诺、允许读取的语义别名。没有这张表不开始评审。
- 评审清单把评论分成两栏：「契约」和「实现建议」。合并与否只由契约栏的未解决问题决定；实现建议不阻塞。
- 禁止把「和设计稿像素级一致」当作通过条件，除非差异落在契约写过的视觉 token 上。
- 验证：抽最近五次准入评审的评论。若超过一半在讨论类名、具体像素或内部文件结构，评审层放错了。再用一个未参与实现的工程师只读接口表去调用该组件：第一次就能选对属性、不打开源码，这张表才算在承担契约。打开源码才能用，接口评审就还没发生。