给产品加新功能时，大家都盼着它跑得快、用的人多。可如果一次批量生成就能产生大量费用，“跑得太顺”也可能让人头疼。
举个设想：一个商家把同一批商品资料重复上传了十次。AI 文案工具尽职尽责，一批接一批地生成，没有报错，费用却一直增加。此时，错误率再低，也说明不了经营是否正常。
软件里的功能开关，就像店里的独立电闸。某个功能出现问题，可以暂时停掉它，其他服务照常运行。比如暂停新的视频生成任务，已经完成的视频仍然能下载。经营者不用为了拦住一种消耗，把整间店都关门。
与它相关的另一个词叫“熔断”。可以把它理解成遇到一类异常后自动暂停尝试。微软的架构文档解释，熔断器会阻止持续失败的调用，之后再放少量请求试探是否恢复。资料：微软熔断模式说明
两者管的事情并不完全相同。功能开关回答“现在是否开放”，熔断关注“继续调用是否还合适”。而前面那个重复上传的例子，还需要费用或数量限制：请求都成功时，单盯着失败次数的保护机制未必会触发。
有意思的是，停止键也可能只是看起来存在。网页上的按钮消失了，之前排队的任务却还在跑；旧页面或者其他入口也可能继续提交。屏幕安静下来，并不代表后台已经停止花钱。
恢复也有讲究。问题原因还在，只是过几分钟重新开放，就可能重复同一场混乱。少量放行、观察结果，往往比一口气全部重开更容易看清情况。
当然，小产品不必堆满复杂控制。开关越多，维护和理解它们也越费劲。关键在于，那些一旦失控就会迅速影响客户、扩大成本的地方，是否有真正有效的暂停能力。
产品能开始工作，是一项能力；知道何时停下来，并把影响限制在一小块地方，同样是一项能力。