上周帮朋友公司看一个后台系统，登录页点了半天没反应，查了半天发现是前端重构时把旧的埋点逻辑全删了——结果运营同学第二天就发现用户行为数据断了一天。这不是bug，是重构惹的祸。
重构不是程序员的自嗨现场
很多人以为重构就是“把代码写得更漂亮点”，换个框架、拆几个函数、加点注释，完事。但现实里，一次没沟通清楚的重构，可能让刚上线两周的优惠券弹窗突然不显示，或者搜索框默认排序从“销量优先”变成“价格最低”，用户找不到想买的东西，客服电话立马爆掉。
比如有个电商后台，技术团队觉得老订单列表接口太慢，直接重写成新版本，字段名全换了：order_status → status_code，pay_time → paid_at。前端按新字段接了，测试也过了。但没人告诉产品经理：导出Excel的功能还指着老字段生成表头。结果运营导出的表格里，“付款时间”列全是空的，连带财务对账卡壳两天。
产品经理该盯哪几件事？
不是让产品经理去改代码，而是守住三条线：
- 用户路径不能断：比如原来从商品页点“找相似”会跳转到推荐页，重构后这个按钮没了，或者点了没反应——这得在原型图或流程图里提前标出来；
- 关键数据不能丢：埋点、日志、上报字段、第三方SDK调用时机，这些得和产品经理一起过一遍清单；
- 对外文案和规则不能变：比如“满199减20”的活动规则文案，如果重构时顺手把提示语改成“立减20元”，看似更简洁，但法务可能说这违反广告法表述规范。
有次我们修一个App的登录态同步问题，技术方案是把token刷新逻辑从客户端移到服务端。听起来很合理，但产品经理翻出历史记录说：去年因为token刷新太频繁，被iOS系统判定为异常行为，导致部分用户被静默登出。最后大家一块儿把刷新间隔、失败降级策略、错误提示文案全重新对了一遍才上线。
真遇到“不参与”的情况怎么办？
不是所有重构都得拉产品经理开会。小范围、纯技术优化（比如把某段正则表达式换成更高效的写法，不影响输入输出），确实不用惊动别人。但只要涉及以下任意一项，建议拉上产品快速过一遍：
• 页面跳转关系变化
• 表单校验规则调整（比如手机号从11位放宽到支持12位国际号）
• 第三方服务切换（如从极光推送换成华为PUSH）
• 任何影响用户看到的内容、按钮、提示语的地方
一句话：代码可以重写，用户习惯很难重养。重构不是给系统“整容”，是给它“续命”。命续得好不好，得看用户还愿不愿意天天来。