上周五晚上十一点，网站我盯着屏幕上那个白屏的源码页面，咖啡已经凉透了。修改客户说网站后台登不进去，经验我F12打开控制台，分享满屏的网站红色报错像瀑布一样往下淌。那一刻我意识到，源码问题不在后台，修改是经验我前天改的那段PHP代码把整个登录逻辑搞崩了。

改源码这事儿，分享说穿了就是网站跟细节较劲。你永远不知道哪一行看似无关紧要的源码代码会在某个特定条件下引爆全局。那次事故的修改根源其实特别蠢——我在一个循环里用了全局变量覆盖，本地测试时数据量小没暴露，经验一上生产环境，分享用户数据一多，内存直接爆掉。

后来我养成个习惯，动任何核心文件之前先备份，不是那种扔个zip到桌面完事，是正经用Git打tag。有一次同事改完一个支付接口，第二天发现订单状态全乱了，回滚到前一天版本，三分钟解决问题。没有版本控制，那种情况只能对着代码哭。

还有一次更邪门。用户反馈说上传图片偶尔会旋转90度，我查了半天，发现是手机拍摄的EXIF信息里带了方向标记，而服务器的图片处理库默认忽略这个标记。解决办法就三行代码，但排查花了我两个下午。从那以后我明白，很多bug不是逻辑错误，是数据本身带着你看不见的“脾气”。

改源码最忌讳上来就动手。我见过太多新手，打开文件看到报错就急着改，结果越改越乱。正确做法是先复现问题，把报错信息完整读一遍，再去搜对应的函数定义。有时候问题根本不在你改的那段代码里，而是上游传过来的数据格式变了。比如接口返回的JSON从字符串变成了数组，你后端的foreach直接报错。

说个具体例子。上个月优化一个查询功能，原来要5秒，我加了索引之后降到0.2秒。但过了两天，用户说某些条件下还是慢。我查了慢查询日志，发现有个关联查询没用上索引，因为我在JOIN的时候对字段做了函数处理，MySQL就放弃索引了。改成只对右边表做函数操作，瞬间恢复正常。这种坑，文档里写得很清楚，但不踩一次根本记不住。

工具链也得跟上。我现在调试PHP用Xdebug断点，不再用var_dump瞎打。改前端代码必开浏览器开发者工具的Sources面板，直接在源码里打断点，比改代码加console.log高效得多。有一次改一个JS交互，我在Sources里改了十几行验证逻辑，确认没问题再复制回编辑器，省得来回刷新页面浪费时间。

说到底，改源码是门手艺活，靠的是耐心和复盘。每次修完一个难搞的bug，我会记个笔记，写清楚触发条件、排查过程、最终方案。三个月下来，我发现自己踩过的坑越来越相似，很多问题看一眼报错就能猜到大概方向。这种手感不是天赋，是拿一个个不眠夜换来的。

对了，如果你刚接手一个老项目，先别急着改功能。找个周末把目录结构捋一遍，看看哪些文件是核心，哪些是冗余。我去年接手一个十年前的PHP项目，光无用文件就删了三分之一，加载速度提升明显。但删之前一定确认没被include，不然等着你的就是白屏加报错。

最后说句实在的，改源码最爽的时刻不是代码跑通那一下，而是你终于搞明白当初写这段代码的人到底在想什么。那种隔空对话的感觉，比任何技术成就感都来得实在。