上一篇我整理了 5 类项目规则其中一条是修改公共组件、公共契约或状态来源之前先查调用方和兼容影响。这句话写进规则不难真正执行时却很容易被简化成搜索一下组件名看看哪些文件导入了它。这只能查到调用链的一部分。前端组件不是一个只被import的函数。它可能通过全局注册使用通过路由或动态组件加载通过包装组件再次暴露它与父级之间还存在 Props、Emits、v-model、插槽和暴露方法。组件内部又可能读写状态、发请求、改路由、操作缓存甚至依赖特定 DOM 结构和外部样式。只找到“谁引用了这个组件”还不足以回答真正重要的问题谁依赖了它的哪一项行为哪些依赖在类型层面可见哪些只在运行时出现组件的输出被谁继续消费某个默认行为改变后会在哪条用户路径上暴露哪些检查可以证明调用方没有被破坏所以我让 Codex 修改组件前查的不是一份引用列表而是一条行为调用链。调用链不是“谁导入了谁”而是行为怎样穿过边界我会把前端组件调用链写成下面这条路径用户入口 → 页面或容器 → 组件输入 → 组件内部状态与副作用 → 组件输出 → 调用方后续动作 → 页面结果其中任何一段发生变化都可能让一个局部修改扩散出去。例如一个编辑弹窗保存成功后触发事件。单看弹窗文件可能只是这样一条输出保存成功 → 触发 saved 事件放进完整链路后真实行为可能是列表页点击编辑 → 传入当前记录标识 → 弹窗请求详情并回填 → 用户提交 → 弹窗调用保存接口 → 触发 saved 事件 → 父页面关闭弹窗 → 保留当前筛选条件刷新列表 → 必要时调整当前页码如果只修改事件名称或关闭逻辑后面的刷新、页码和筛选状态都可能受影响。这就是“组件文件只改了几行页面行为却变了”的来源。第一个误区搜索组件名就认为找到了全部调用方名称搜索很有用但它默认只能找到文本中可见的引用。下面这些情况很容易漏掉经过统一出口再次导出业务文件可能不是直接导入目标组件而是从组件库入口、模块索引或别名路径导入。经过包装组件使用页面使用的是BusinessDialog真正修改的是内部的BaseDialog。直接搜索目标组件只会找到包装层真正依赖默认行为的是更上层页面。全局注册模板中直接使用组件标签没有本地导入。名称映射可能发生在应用入口或自动导入配置中。动态组件组件由配置、映射表或字符串名称决定。静态搜索可能只找到注册表找不到真实业务路径。路由或文件扫描页面组件可能由路由生成、模块扫描或约定式目录自动接入文件中没有一条直观的手写引用。所以第一轮搜索得到的是“候选调用方”还需要沿导出、注册、包装和入口关系继续向上确认。我会要求 Codex 给每个调用方标注发现方式直接导入、二次导出、包装、全局注册、动态映射或路由入口。这样能看出哪些结论可靠哪些仍需要运行路径验证。第二个误区只查组件文件不查它的公开契约组件调用链的核心是公开契约。我至少会让 Codex 检查 5 个位置。Props不只看属性名称还要看是否必填默认值是什么是否允许对象被组件内部修改父级传入的是原始状态、计算结果还是临时副本多个属性之间是否存在隐含组合规则。把一个可选 Prop 改成必填类型检查可能暴露部分影响改变默认值则可能悄悄改变所有没有显式传值的调用方。Emits 与v-model要查事件名称、触发时机、事件负载和消费方式。同一个事件可能被不同页面用于关闭弹窗刷新列表更新本地对象触发下一步流程记录操作结果。如果只确认“父级监听了事件”仍然不知道事件行为变化会影响什么。插槽插槽依赖往往不容易通过类型和普通引用搜索发现。调用方可能依赖具名插槽是否存在插槽作用域暴露哪些数据DOM 包裹层级空插槽时的默认内容插槽渲染顺序。删除一层容器看似只是模板整理可能破坏插槽布局或外部样式。暴露方法与组件引用父级可能通过组件引用调用open、reset、validate或其他方法。这类依赖未必出现在 Props 和 Emits 定义中。修改方法签名、返回值或调用时机需要查所有组件引用和类型声明。透传属性与原生事件一些组件会把未声明属性、类名或事件继续传给内部节点。调用方依赖的行为可能没有被组件 API 明确写出却在页面中真实存在。公开契约查完后我才知道组件修改是内部实现变化还是已经触碰外部行为。第三个误区只向上找调用方不向下查状态和副作用调用链有两个方向向上谁使用组件、怎样消费它的输出向下组件依赖什么状态、请求、路由和公共能力。很多影响并不来自组件 API而来自内部副作用。例如组件可能打开时请求详情写入共享状态修改路由查询参数更新浏览器缓存订阅全局事件注册定时器触发埋点或日志在卸载时清理资源。如果修改初始化时机受影响的可能不只是当前页面还包括共享状态的其他消费者如果把请求从打开时改到首次挂载缓存页面和重复打开路径可能出现不同结果。我会让 Codex 为每个副作用回答四个问题谁触发它它读写什么外部状态成功、失败和取消时分别怎样收尾还有谁会观察到这次变化。这一步能把“组件内部重构”中隐藏的全局影响暴露出来。第四个误区忽略生命周期和调用顺序同一组函数执行顺序不同行为可能完全不同。前端组件里需要特别检查首次挂载每次打开Props 变化路由切换缓存激活与失活弹窗关闭组件卸载异步请求返回。例如父级先更新记录 ID再打开弹窗组件可能监听 ID 变化请求详情也可能在打开动作中读取 ID。如果 Codex 只看到两段逻辑都存在就可能把它们合并成一个更“简洁”的初始化函数却改变了调用顺序。调用顺序还会影响旧请求是否覆盖新对象校验信息何时清除Loading 是否在关闭后继续默认值是否在回填后被重置父级刷新是否发生在弹窗关闭前后。所以调用链不能只画静态箭头还要标记关键时间点。第五个误区DOM 和样式没有 import就不算依赖组件模板改变经常会产生代码搜索难以发现的影响。调用方或全局样式可能依赖特定类名子元素层级第几个子元素深层选择器组件根节点属性透传位置固定尺寸或溢出行为。测试也可能依赖文本内容标签语义data-*标记可访问名称DOM 查询路径截图基线。因此“只改模板结构不改功能”不代表影响范围小。我会把样式、测试、故事、示例和文档视为组件的外围消费者。它们不一定全部要修改但必须进入检查范围。我让 Codex 查调用链的实际顺序第一步先写清准备改变什么调用链范围取决于改动类型。“修改内部变量名”和“改变默认关闭行为”需要查的范围完全不同。开始前先写一条变化声明准备改变 - 哪个可观察行为或公开契约 - 保持不变的行为 - 当前认为是内部实现的部分如果连变化是什么都说不清搜索会无限扩散。第二步列出组件全部公开面包括 Props、Emits、v-model、插槽、暴露方法、属性透传、根节点和公开类型。这一步得到“可能传播影响的出口”。第三步查组件怎样进入项目沿直接导入、统一导出、包装组件、全局注册、动态映射、路由和自动扫描确认真实入口。这一步得到“谁可能使用它”。第四步逐个查看调用方怎样依赖不能只记录文件名要记录使用的契约和依赖的行为调用方使用方式依赖内容变化后风险页面 A直接使用Prop 默认值、保存事件可能改变刷新时机包装组件 B二次封装插槽与暴露方法可能继续影响上层页面动态入口 C配置映射组件名称与属性透传需要运行时确认第五步向下追踪状态和副作用确认请求、状态、路由、缓存、全局事件和生命周期清理。这一步得到“组件会改变什么外部状态”。第六步补查外围依赖包括样式、测试、故事、示例、文档和类型使用。第七步把未知项变成暂停条件例如动态组件入口无法静态确认插槽作用域存在未声明使用两个调用方依赖相反的默认行为公共类型被其他应用复用页面验证环境无法启动。未知项没有解决前不应该让 Codex 假设“其他调用方不受影响”。我会要求一份“调用链交付物”# 组件调用链检查 ## 1. 计划变化 - 要改变的行为或契约 - 必须保持不变 ## 2. 组件公开面 - Props - Emits / v-model - 插槽 - 暴露方法 - 透传与根节点 - 公开类型 ## 3. 进入路径 - 直接导入 - 统一导出或包装 - 全局注册 - 动态组件、路由或自动扫描 ## 4. 调用方 | 调用方 | 使用契约 | 依赖行为 | 影响类型 | 验证方式 | | --- | --- | --- | --- | --- | ## 5. 下游依赖 - 状态 - 请求 - 路由 - 缓存与全局事件 - 生命周期清理 ## 6. 外围依赖 - 样式 - 测试 - 示例与文档 ## 7. 结论 - 直接影响 - 间接影响 - 条件性影响 - 尚未确认 - 是否可以进入修改计划这份交付物不应该退化成几十个文件名。每个文件都要说明它通过哪条契约或行为与组件发生关系。直接、间接和条件性影响要分开直接影响调用方明确使用了即将变化的 Prop、事件、插槽或方法。间接影响调用方使用包装组件、共享状态或公共类型变化经过中间层传播。条件性影响只有特定路由、权限、配置、环境、数据或操作顺序下才出现。三种影响的验证方式不同。直接影响适合类型检查和目标页面回归间接影响需要沿包装与状态继续追踪条件性影响则必须写清触发条件不能用一次正常路径代替。哪些情况下可以停止继续查调用链也不能无限扩张。我通常在下面几个条件成立时停止组件所有公开面已经列清每个入口都能对应到真实调用方或明确排除计划变化能映射到具体依赖行为状态、副作用和生命周期责任已经定位样式与测试的关键依赖已检查每类影响都有验证出口剩余未知不会改变实现方向或已明确标成后续人工验证。目标不是理解整个项目而是证明当前改动不会越过尚未看见的责任边界。写在最后修改前查调用链不是为了生成一份漂亮的依赖图而是为了回答三个问题这个组件的哪些行为对外构成契约谁直接、间接或在特定条件下依赖这些行为修改以后分别用什么证据证明调用方仍然成立。仅搜索组件名最多找到部分静态入口。真正的调用链还包括 Props、Emits、v-model、插槽、暴露方法、状态、副作用、生命周期、DOM、样式和测试。下一篇我会把这份调用链进一步转成影响范围评估表怎样区分内部实现、公开契约和用户行为变化怎样确定需要修改与只需回归的位置以及怎样据此调整 Codex 的执行批次和验收路径。本系列持续更新。接下来会从“找到依赖”进入“判断影响”为后面的代码差异审查建立一条清楚的基线。每日好工具推荐在这里推荐一款超好用的图片压缩工具——“图压”在线图片压缩免费压缩 JPG、PNG、WebP - 图压工具。同事安利给我的用过后真的觉得太香了支持批量压缩、调整压缩百分比最关键的是它是离线程序下载到本地就能反复用。我平时做自媒体和写前端时经常用到再也不用去网上找在线压缩工具了。它也带在线压缩功能很方便。