上一篇做完“列语义表”，还不能直接进入交付。设计规则是否真的落到了模板里，需要重新沿每一列检查一遍。

我不太喜欢只拿一行正常数据验表格。正常数据会把很多问题藏起来：字段都有值、标题长度刚好、状态都在字典里、当前账号又拥有全部权限。这样的页面当然容易显得完整。

更有效的做法，是给不同类型的列准备不同的检查值。空值列看缺失语义，文本列看极端长度，状态列看未知代码，操作列看权限与行状态组合。

这不是编造测试结果。下面给出的是验收设计；只有在真实项目中执行过对应步骤，才能记录为通过。

先按列类型分组，不从左到右机械检查

我会先把列分成几组：

• 标识和普通文本；

• 数值、金额与计数；

• 时间和范围；

• 枚举与状态；

• 图片、链接等特殊内容；

• 操作列。

同一组共享一部分风险。例如数值列要防止把 0 当空值，状态列要检查未知代码，特殊内容要考虑加载失败和安全边界。

按风险分组，比从第一列一路看到最后一列更容易发现一致性问题。它也便于给 Codex 下达局部任务：只修改状态展示时，不要顺手调整所有列宽。

空值验收：先定义“空”，再看占位

我会为相关字段准备下面几种输入：

null
undefined
''
0
false
[]

这些值不能被同一个 value || '-' 处理掉。

代码审查阶段可以确认条件判断是否误伤 0 和 false，也能看出空数组是否被直接渲染。页面阶段则要确认占位符是否与列对齐、Tooltip 是否对占位符生效，以及空状态有没有被误认为加载中。

我还会追一层业务含义。某列没有数据时，是没有填写、没有权限、暂未计算，还是接口没有返回？如果含义不同，就不该全部显示成同一个短横线。

因此，空值检查的交付结果不只是“统一加了 -”，而应该记录每类列的缺失策略。

长文本验收：至少看四种长度

短文本无法证明列宽合理。我会准备：

1. 一个正常名称；

2. 接近预期上限的内容；

3. 明显超过列宽的连续文本；

4. 包含换行、空格或中英文混排的文本。

随后检查省略、Tooltip、复制和横向滚动。

Element Plus 的 show-overflow-tooltip 能提供常用的溢出提示，但它不替代内容策略。连续英文或编号未必按中文自然换行；Tooltip 也可能被弹层层级、容器裁切或敏感信息要求影响。

如果用户经常需要比对完整内容，我会考虑扩大 min-width 或把关键内容移到更合适的位置。如果只是偶尔查看，省略加提示更合适。没有页面和数据证据时，这仍是待验证决定。

状态列验收：正常映射只是第一步

状态列至少要覆盖三种输入：已知状态、未知状态、缺失状态。

已知状态检查文字和样式是否来自项目统一配置。未知状态用来验证前后端版本暂时不一致时，页面会不会显示空白。缺失状态则要判断它与“未知代码”是否同义。

如果状态还会控制操作按钮，需要把组合一起列出来：

行状态	编辑	删除	查看	依据
草稿	按权限决定	按权限决定	可查看	业务规则
已发布	可能禁用	可能禁用	可查看	业务规则
未知状态	默认收紧	默认收紧	视项目策略	风险兜底

表中内容只是结构模板，不是某个具体业务的既定规则。实际按钮权限必须来自需求、项目代码或用户确认，Codex 不能根据状态名称自行补全。

时间列验收：格式正确还不够

时间列需要核对原始值类型、格式化入口和空值。时间范围还要检查只有开始时间、只有结束时间以及二者顺序异常时怎样展示。

当前 web-skills 提供 getTimeFun，也有起止时间组合展示的范例。在目标项目采用这套规范时，我会优先复用，避免在插槽里重复切字符串。

但工具函数能格式化日期，不会替我决定时区、精度和业务文案。列表要显示到日、分钟还是秒，应该由页面用途决定。涉及跨时区数据时，更不能把本地 Date 转换当作默认正确答案。

操作列验收要拆成“看得见”和“做得到”

权限控制常被误解成隐藏按钮。实际上需要分开验证：

• 当前用户是否看见按钮；

• 按钮是否因行状态禁用；

• 即使绕过界面，接口是否仍有权限保护；

• 点击后是否进入正确弹框和数据流；

• 操作结束后列表怎样刷新。

web-skills 中的 v-disOperation 负责项目内的前端操作权限表现，useDialogImp 负责弹框状态，delRow 连接确认和刷新。它们各自解决一段问题，不能互相代替，也不代表前端权限能替代后端鉴权。

我会特别看编辑按钮传递的行数据。如果把响应式行对象直接交给表单，用户尚未保存，表格内容可能已经跟着变化。项目采用传 ID 后获取详情，还是复制行对象，要以既有范式为准。

特殊列不要只验证成功路径

图片列要检查空地址、加载失败、比例异常和预览；链接列要检查文本、地址来源和打开方式；富文本摘要要避免直接把未经处理的 HTML 塞进表格。

当前项目规范包含 viewImg 和 noData 等公共组件。使用它们之前仍要读清输入契约，尤其是基础地址、预览和失败占位，不能只看组件名猜行为。

这类列如果没有真实需求材料，我不会为了让文章显得完整而编造一套实现。更稳妥的做法是列为按需检查项，等具体页面出现时再验证。

哪些能看代码，哪些必须打开页面

我会把验收证据拆开：

检查项	代码审查	页面验证
字段来源和转换函数	可以确认	用真实响应复核
0、false 是否被误判为空	可以确认	确认最终文字和样式
长文本是否配置省略	可以确认	必须看宽度、Tooltip 和滚动
状态映射是否覆盖未知值	可以确认	确认颜色、文案和可读性
权限指令是否使用	可以确认	换不同权限账号或模拟条件验证
固定列和横向滚动	只能看到配置	必须在不同宽度页面检查
点击后的弹框和刷新	可追调用链	必须走完整操作路径

这张表能防止两种假完成：只看页面说“没问题”，却不知道参数和权限从哪里来；只看代码说“已经处理”，却没发现 Tooltip 被遮挡、列宽失衡或固定列抖动。

我会让 Codex 输出逐列验收结果

请按列类型验收本次表格改动，并输出：
​
1. 已检查的字段值域：正常、空值、0/false、超长、未知枚举。
2. 每列使用直接 prop、插槽或公共组件的理由。
3. 代码审查已经确认的结论及对应文件位置。
4. 必须进入页面验证的项目，不得写成已通过。
5. 操作列的权限、行状态、弹框、接口和刷新路径。
6. 未验证项和所需环境。
​
只修改当前任务涉及的列，不顺手统一全表样式。
项目已有格式化、图片、权限和按钮组件时优先沿用。

这份结果不要求 AI 宣布“全部完成”，反而允许它明确写出未验证。对工程交付来说，诚实的未验证项比一句“展示正常”更有价值。

写在最后

逐列验收并不是把表格测试变得繁琐，而是让不同类型的数据接受与风险相匹配的检查。

普通文本、状态和操作列表面上都占一个单元格，背后的契约完全不同。把它们分开检查，Codex 才不会用同一种模板处理所有内容。

下一篇将进入分页问题。重点不是再讲一次“新查询回第一页”，而是沿接口响应、总数、页码和删除后的数据变化，定位页码与列表错位究竟发生在哪一层。

本系列持续更新，后续仍会在每篇写作后运行表达质检与真实性复核。