副作用Side Effect
你可能会说
用户只是在预览价格，不能悄悄写入订单或发邮件；真正提交时再明确执行这些动作。
函数或请求除了返回结果，还改变了外部状态或触发了外部动作。例如用户只是预览运费，代码却顺手写入报价记录并发出邮件；预览本身的计算应先返回结果，真正保存和通知应由用户明确提交。副作用不是错误，关键是它是否显式、可控、可验收。
也常被叫作副作用操作外部影响
延伸阅读 · 权威出处
用户只是在预览价格，不能悄悄写入订单或发邮件；真正提交时再明确执行这些动作。
用户只是预览，却产生了写库和发送邮件的副作用。
问题与关键机制：用户只想预览运费和总价，旧接口却写入报价记录并发送邮件；把价格预览和明确提交分开，只有点击“确认下单”才保存订单并发送通知。
怎样观察改善：只有用户明确确认下单时，才保存订单、扣减库存或发送通知，并返回每个动作的真实状态。验收时确认预览不会新增记录或发送邮件，确认下单只产生一次预期记录和通知。
第二个场景：内容发布：编辑者只是在预览文章时，系统不应发布草稿或通知订阅者；这些外部改变要等用户明确点击“发布”后再执行，并分别核对发布状态和通知结果。
请把报价预览和下单提交分开：预览接口只计算并返回价格，不写报价记录、不发邮件；用户明确点击确认下单后，才保存订单并触发一次通知。补测试验证预览调用不会新增记录或发送邮件，提交一次只产生预期的一次外部改变。