一个手持终端拣货流程从后端收到了目标字段，但当该字段使用约定的星号哨兵值时，页面不显示目标，暂存和确认按钮也无法通过必填校验。

普通目标值一直正常，因此最初看起来像是接口偶发缺字段。沿着响应、页面状态和提交参数逐层检查后，问题被定位到客户端的一段“规范化”逻辑。

证据

后端响应中存在字面星号，数据模型也允许字符串原样保存。客户端在把字段写入页面状态前，却主动将星号转换成空串。

这个转换影响的不只是显示文本。同一个规范化结果还被用于：

• 商品卡片和确认弹窗回填；
• 目标字段的必填判断；
• 暂存及确认请求的目标参数。

因此一个看似只为界面清理而写的条件，同时切断了展示、校验和提交三条链路。

根因

星 …

物流系统中的小 Bug 经常反复出现，不一定是规则没有写，而是规则只写在某个按钮、页面或异常分支里，没有覆盖真正改变业务状态和数据的入口。

下面四类缺陷来自不同功能，但中心问题相同：业务规则必须放到真正改变状态或数据的共同操作中，并让所有入口返回一致的处理结果。

编辑权限必须约束动作，而不只是按钮

费用详情只允许在 NEW 或 REJECTED 状态编辑。页面隐藏了部分按钮，但表格事件仍能打开编辑框，导致已经进入财务流程的数据存在被修改的风险。

修复不能停在视觉层。编辑动作的统一入口必须先检查状态，后端也需要拒绝越权更新。验证时不仅点击可见按钮，还要覆盖行事件、快捷操作和直接请求。

这说明权限 …