组件复用中的状态边界状态变化要有单一入口复用组件时父层负责保存事实组件负责把用户动作转换成事件。输入值更新、校验失败和提交完成最好走同一条数据流。若组件内部为了方便又维护一份副本就要明确什么时候同步、什么时候丢弃旧值否则切换页面或异步回填时显示状态很容易和业务状态分叉。先把对象说清楚江吟月处理前端里的“组件复用中的状态边界”时通常不会先讨论工具多不多而是先把任务压到一个具体场景谁在什么条件下发起操作系统需要留下什么结果哪一步出错必须停止。只要这个场景还说不清后面的架构图和参数表就很容易变成装饰。落地时先把会被谁使用、输入从哪里来、输出落到哪里写进任务说明。不要把一个宽泛的需求拆成很多漂亮的名词真正需要确认的是每个动作是否会改动状态、是否依赖外部服务以及失败后用户会看到什么。把这些问题放到实现前比上线后靠日志猜原因省事得多。处理这类问题时我会先挑一条最常见的路径跑通再故意让它遇到缺字段、超时、权限不足和重复提交。记录的重点不是“测试通过”而是当时的输入、版本和结果。能复现的记录才能帮助后来的人判断改动影响。组件复用的关键是分清谁拥有状态。字段值、校验结果与提交动作应由业务层决定展示组件只接收数据并抛出事件。当多个页面需要同一组件时先提取稳定的属性与事件不要把某个页面的接口请求塞进组件内部。受控与非受控模式只能选一种作为主路径混用会让同步时机变得难以推断。沈砚舟会先画出状态流向再决定抽象层级清晰的边界往往比更多的配置项更有用。用真实场景收住实现留下可复查的取舍补充时不必把所有可能性写成一张清单。围绕当前页面最容易变化的输入和状态先把可见行为做稳定其余情况留出明确入口等有真实需求再扩展。写完实现后用一段短说明把取舍留下来这次优先保证了什么哪些情况仍需要确认出现异常时用户会看到什么。它不是为了把文档写得漂亮而是防止下一次需求变化时大家只看到代码表面忘了原先为什么这样处理。前端的复杂度常来自边界叠加能把边界说清就能少一些临时补丁。这类前端问题不能只在默认页面里判断。补一个真实的变化场景内容变长、接口返回空结果、用户连续点击或者在网络较慢时切换页面。观察组件、样式和请求状态会怎样配合而不是只确认画面是否好看。很多隐患并不藏在复杂逻辑里而是某个默认值、一次未清理的订阅或一条覆盖规则在边界条件下失效。修改时最好一次只处理一个明确原因并留下能复现的步骤。若需要取舍就把限制写在组件说明或任务记录里例如哪些输入暂不支持、哪种浏览器有降级路径、错误发生后页面会保留什么。这样后续继续迭代时接手的人能知道原来的判断依据不会为了修一个局部问题又把状态、布局和接口行为重新搅在一起。