首先单从开发的角度，任何东西都可以修改，但是也要考虑实际场景。
比如修改的成本大不大？比如底层架构问题，就像是你盖了一幢楼，你现在要把一楼的结构调整了，能直接改吗？承重墙能拆了吗？当然不能。
会不会影响系统稳定性？比如干扰到其它功能，或者有潜在的风险会干扰到其它功能。
会不会影响数据一致性？
会不会不符合业务逻辑？
这些都要考虑，最终综合考虑下再设计修改规则。
正所谓，无规矩不成方圆，规矩限制虽然限制了某些东西，但是使整体效果更好更通畅。
在软件产品中定义规则，主要有不可修改，限定条件修改等。
以淘宝退货单的提交为例。
退货单提交，属于限定修改的设计，提交后不能再直接修改。在客服拒绝了你的退货的条件下，才可以修改。为什么这样设计？
首先了解业务场景：
电商行业的已发货退货退款常规流程：消费者提交申请--客服同意--消费者寄回货物--WMS退货入库--退款。
物流单号非常重要的意义之一：WMS需要参考物流单号匹配实物退货入库。从这个角度来说物流单号对于下游的收货意义非常重要。
虽然物流单号很重要，但对WMS的退货入库条件来说并不是唯一的。WMS仍然可以通过订单号、电话号码等等条件匹配到你的退货申请。这也是很多商家会要求用户在退回时填写退货卡的原因，退货卡会要求填订单号、手机号等等信息。
其次，了解系统逻辑
在系统设计中有个叫状态机的东西，一般我们描述是说在XXX状态下允许修改XXX；
等待商家收货并退款状态下不允许任何修改，但是商家可操作拒绝退货或消费者可操作撤回申请后，可修改。
当我们无法确定修改物流单号这个需求是否合理的时候，我们问两个问题：
1、满足了这个需求会发生什么？
如果我们允许在“等待商家收货并退款”的状态下修改快递单号会发生什么呢？
我觉得也没啥？无非就是平台多更新几次，多一点校验。但是这就是完全为了极少发生的场景增加系统的复杂度。
2、我们可以再问一下，不满足这个需求会发生什么，我们是否有替代方案？
我们可以通过客服是可以通过拒绝申请让消费者修改，或者消费者自己撤回也行。
最后，让我们回到业务。
一般情况下，消费者不会乱填物流单号，因为匹配不到实物退货，不能退款，对商家来说最多就是拒绝你的退款，没有任何损失，而对于消费者来说， 是无法收到钱的，损失的是真金白银。。
当然有没有抬杠的用户这些都不填或者乱填呢？当然有，这些就会进到无头件。至于无头件的处理是另外一种逻辑
关注我们：请关注一下我们的微信：扫描二维码
（鼠标移入红色字）版权声明：本文为原创文章，版权归 admin 所有，欢迎分享本文，转载请保留出处！
