响应式协作：并发时先守住组件契约
状态名要能解释页面
不要用一个笼统的 loading 覆盖所有过程。请求取消、空结果和重试失败应有不同状态，调用者才知道该保留旧内容、显示提示还是允许再次操作。
多人同时调整一个页面，最容易被悄悄破坏的是组件契约：同一个按钮在某个宽度不再可点，卡片把外层布局挤坏，或者空状态和加载状态只改了一半。并发不是问题，缺少边界才是。
小改动也要有状态覆盖
每个响应式组件至少确认正常、长文本、空内容和不可用状态。页面级分栏可以后补，阅读顺序和关键操作不能等。改动跨越组件边界时，先把公共 Token 和 API 说清楚。
.actions { display: flex; flex-wrap: wrap; gap: var(–space-2); }
.actions > * { min-inline-size: max-content; }
合并前看真实差异
截图测试固定字体、数据和动画，并和 DOM 断言一起用。冲突发生时，回到组件的输入输出判断，不以谁先改为准。这样并发再高，也不会靠临时补丁维持布局。
契约要落在能检查的位置
组件协作出问题，常常不是某个人写错了一行代码，而是两边对“加载结束”理解不同。一个组件把空数组当成功，另一个还在等待；一个组件销毁时取消了请求，父级却在回调里继续 setState。把这些约定只写在评审评论里没有用，应当写进类型、测试或状态图里。状态名不用多，能分清初始、加载、成功、空结果和失败就够了。
并发触发时尤其要说明后来的请求是否覆盖先来的请求。搜索框、筛选器和分页都会遇到这个问题。可以给请求编号，响应回来时只接收当前编号；也可以在参数变化时取消旧请求。两种做法各有代价，但最坏的做法是让旧响应悄悄覆盖新界面，再让用户怀疑数据是否丢了。
我会让组件测试覆盖一次真实的交接：父级切换参数、子级显示旧内容、网络返回、组件卸载。这里不需要堆很多快照，几条能说明状态流向的测试就能防住大部分回归。接口稳定并不等于永远不改，而是改动发生时，调用方能在编译、测试或日志里尽早发现，而不是上线后才从页面的闪动里猜原因。
组件的可用宽度、可选操作和状态优先级，不必写成很长的规范，但要有一处稳定的示例。比如卡片标题允许换两行，操作区可以换行，空状态不应把列表区域撑满。把这些场景做进 story 或示例页，新成员修改样式前就能看到组件承担的边界。
协作时最容易出现的是两边各自合理、合起来出错：一边给按钮加了最小宽度，另一边把容器改成不换行。代码评审应同时看改动前后的窄屏和长文本，不只盯着各自文件。遇到这样的冲突，与其继续叠加媒体查询，不如回到布局规则本身，确定谁负责收缩、谁负责截断。规则清楚后，后续改动会少很多意外。
发布后若发现状态遗漏，不要只补一个条件判断。先补出能复现的用例，再决定字段是否需要新增。这样既能修住眼前的问题，也避免组件在下一次组合时继续带着模糊约定运行。
交接信息别藏在口头约定里
一次改动交给另一位同事前，我会在合并说明里写出组件依赖的状态和已覆盖的尺寸，而不是只贴一张宽屏截图。特别是请求被替换、组件卸载和重试同时发生的地方，写明旧结果会被丢弃还是暂存。后来的人沿着这几条信息就能复现问题，也知道改样式时不能顺手改变状态语义。
