# 2.0 接入更新 · 2026-09-16

当前已提供 NJWLTable.deleteRecord 与标准 mount 的 remove/canDelete 回调；下方9月15日记录为原规范背景，原“不新增接口”状态已被2.0取代。请以 [2.0 API](/module/table/2.0.0/API.md) 和 [接入清单](/module/table/consumers.md) 为准。

# 表格删除交互规范



更新：2026-09-15。适用于可编辑表格的单条记录删除。



## 状态与实现边界



本次同步控件接入说明、通用开发规范与接入提示词。CRM 已通过业务适配层实现列表删除；公共表格组件 1.0.0 / 1.1.0 源码、接口和版本未因本次文档更新而改变。不要假设已有 canDelete、onDelete 等组件参数；按所用版本 API，在应用操作列及业务接口中实现，若需新增组件公共能力则另提特性并发布新版本。



## 通用交互要求



1. 删除权限独立于编辑权限。可编辑且具备删除权限时，每行操作区提供明确的“删除”入口；只读或无删除权限时不提供可执行入口。服务端仍必须验证账号、记录归属与权限。

2. 确认框显示记录名称及具体影响范围，提供取消与确认；是否可撤销按后端真实能力说明。取消不能发出写请求。存在未保存草稿时，先处理草稿再删除。

3. 确认后显示“删除中…”，禁用重复提交及冲突操作。按钮有可读名称并支持键盘操作，操作列应保持紧凑、不挤压数据内容。

4. 请求携带稳定记录 ID 和版本。服务端检查权限及版本，旧窗口不得删除已被他人更新的记录；返回冲突后保留行并提示刷新。

5. 服务端明确成功后移除行，重新计算数量、分组及空状态，保留原筛选和排序视图。删除成功但刷新失败时，明确提示“已删除，刷新失败”，不得把它描述为删除失败。

6. 删除失败保留记录并恢复可操作状态。网络结果不明时先刷新核对，不假定成功或盲目重复删除。

7. 删除维护历史与业务操作同一事务完成，包含操作者、时间、记录标识、原版本及受影响内容；不能伪造身份，不把真实内容写入运行日志或提供给 AI。



## 应用负责的业务规则



确认文案、关联影响、软删除或硬删除、能否恢复、审计保留和服务端授权由应用决定。CRM 当前示例为“联系人和关联礼物信息一并删除，维护记录保留”；此为 CRM 业务规则，不能硬编码为通用组件默认行为。



## 虚构数据验收



- 两种页面模式及独立删除权限；鼠标和键盘可操作。

- 取消无请求、确认成功、重复点击、保存中互斥。

- 请求失败、结果不明、版本冲突、跨账号拒绝。

- 成功后数量/分组/空列表与刷新结果一致，删除后的维护历史仍保留。

- CRM 已用虚构数据验证列表入口、取消、删除、冲突保护、刷新和维护记录。本清单中其余应用场景须由接入方验证，不能直接宣称通过。