企业官网建设流程全解析

打开编辑器，满屏的代码底下爬着一条条黄色波浪线，左边还有个黄色小灯泡一直在闪。新手第一次撞见这个场面，十个里有八个会以为代码写坏了，赶紧把能删的都删掉，结果程序反而跑不起来了。所谓"黄色代码"，其实是个民间叫法，专业领域里没有这个词，它指的是编辑器和各类检查工具给你打的警告级标记——比红色的错误轻一档，比蓝灰的提示重一档。它不代表代码不能跑，很多时候恰恰说明代码能跑，只是跑得不够稳、不够规范、不够让人放心。这篇内容面向刚入行的初学者，也适合那些写了半年还是被黄色提示搞得心烦的朋友，我会把黄色提示的来路、判定逻辑、处理流程、速查修法一次性讲透，让你以后再看到那一片黄，能像老手一样三秒钟判断：这条要改，那条可以不管。

1. 先搞清楚：编辑器里的"黄色"到底在提醒你什么

1.1 红黄蓝三色信号的分工

现代编辑器基本都遵循一套约定俗成的颜色语义，这套语义不是某一家的专利，而是十几年工具链演进下来形成的共识。红色波浪线代表错误（Error），通常意味着语法层面已经崩了，或者类型系统判定这段代码根本不可能正常工作，编译器直接拒绝继续往下走；黄色波浪线代表警告（Warning），意思是这段代码语法上合法、能编译、能执行，但存在潜在风险或者不符合团队约定的规范；蓝色、灰色或者点状下划线代表提示（Info/Hint），属于"顺嘴一提"级别，比如这里可以简化一下、这里有个更现代的写法。

理解这个分级的意义在于，它对应的是确定性的强弱。错误是百分之百确定有问题，警告是"很有可能有问题"，提示是"可能更好"。新手最容易犯的错，就是把警告当成错误，一看到一片黄就觉得天塌了；另一个极端是把所有警告都当噪音，长年累月视而不见，最后项目里积压几千条警告，真正的雷就埋在里面。

我还见过一种情况，有人把编辑器的字体主题换了，字符串字面量变成黄色，于是满屏"黄色代码"，紧张半天。这类纯视觉的误判很容易排除：把鼠标移到带颜色的位置，如果弹出一段说明文字，那就是检查器的标记；如果没有反应，只是语法高亮，那纯粹是主题配色，不用管。

1.2 为什么新手一看到黄色就慌

这种慌张有很现实的来源。第一，编辑器的默认视觉设计本身就在制造焦虑——黄色是高饱和度的警示色，心理学上天然带紧迫感，一条黄色波浪线在视觉权重上甚至盖过了旁边的正常代码。第二，新手还没有建立起"代码质量分层"的概念，在他们的认知里代码只有"对"和"错"两种状态，警告这种中间态无处安放。第三，教程和文档里很少专门讲这件事，搜索引擎里搜"黄色波浪线"出来的答案又常常是"关闭检查"，治标不治本。

我在带新人的时候会先做一个演示：故意写一段有警告的代码，让它正常跑出结果，然后再把警告改掉，让它跑出同样的结果。这个对比很直观地告诉他们——警告不影响这次执行结果，它影响的是下一次。下周你回来改这段代码，或者你的同事接手这段代码，那个被忽略的警告就会变成理解成本。

还有一层心理因素值得说：满屏黄色其实是一种信息过载。一个文件里如果只有一条警告，你会认真看；如果有两百条，你的大脑会自动把整片区域标记为"无关噪音"。这就是为什么很多项目干脆把警告全关了——不是因为警告不重要，而是因为没人治理过的警告等于没有警告。这一点后面讲配置的时候会展开。

1.3 一张表看清"黄色代码"的五种出处

新手看到的黄色，来源其实五花八门，处理方式完全不同。先把出处分清，比急着动手改重要得多。

表格里最容易被误判的是最后一行。浏览器控制台里那些黄色的 console 警告，很多来自第三方依赖库的弃用提示，跟你写的业务代码一点关系没有。我见过有人为了消掉一条依赖库的黄色告警，硬是把自己能跑的项目改出了 bug，这就属于典型的用错力气。

2. 黄色提示的四大来源与背后的判定逻辑

2.1 语法与语义层：能跑，但可能跑错

这一层是最核心的，也是新手最该学会读懂的。语法层警告的典型代表是"变量声明了但没使用"、"函数有分支没有返回值"、"循环条件里的变量在循环体内被修改"、"不可达代码"。这些代码都能执行，但它们是意图不明确的信号。

拿"声明未使用"来说，检查器的判定逻辑很朴素：它建立了一张符号表，记录每个标识符的声明位置和所有引用位置，如果某个声明在作用域结束前一次引用都没有，就报一条警告。工具并不知道你是忘了用，还是打算以后用，还是调试代码残留，它只是把这个事实指出来。所以这条警告的正确处理方式不是无脑删变量，而是先问自己：这是我漏写了逻辑，还是残留的调试代码？

再看"函数缺少返回值"。检查器会遍历函数的所有执行路径，如果存在某条路径走到函数末尾却没有 return 语句，而函数的其他路径有返回值，它就判定这条路径会隐式返回 undefined（在 JavaScript 这类语言里）或者返回一个不可预期的值。这类警告的价值极高，因为它在静态阶段就能抓出"某些情况下拿不到预期结果"的隐患，而这种 bug 在测试里往往很难复现——只有特定的输入组合才会走到那条路径。

还有一类是"变量遮蔽"（shadowing）。内层作用域声明了一个和外层同名的变量，检查器会提醒你。新手常觉得这是多管闲事，直到某天在一个嵌套三层的循环里，因为遮蔽问题把外层计数器改掉了，排查了整整一个下午。这类警告属于"当下无害、未来致命"，我的建议是一律处理掉，成本很低。

2.2 风格与规范层：不影响运行，影响协作

风格类警告是数量最多、也最容易让人抓狂的一类。缩进用了两个空格还是四个、字符串用单引号还是双引号、行尾有没有多余空格、每行超过八十个字符、import 语句的顺序不对——这些统统会亮黄。它们的共同特征是：对程序行为零影响，对团队协作影响很大。

为什么团队要管这些？因为代码的阅读时间远远超过编写时间，比例大概是十比一甚至更高。如果每个人的风格都不一样，一个人读别人的代码就要多花额外的注意力去过滤风格差异，这部分注意力本来应该用在理解业务逻辑上。规范的本质是降低协作中的认知摩擦，不是形式主义。

但这也带来一个问题：对于个人项目或者学习阶段，风格警告的优先级确实很低。我不建议新手一开始就把所有风格规则开满，那会让人把大量时间花在调缩进上，而不是写逻辑。比较合理的做法是先开"能抓真 bug"的那部分规则，风格类的可以交给工具的自动格式化功能统一处理。

这里有个细节值得说：风格警告往往带"自动修复"能力。检查器之所以能自动改，是因为这类问题有唯一确定的正确答案——多余的空格删掉就行，引号统一就行。而语义类警告基本没法自动修，因为怎么修取决于你的意图。这个区别本身就是判断警告类型的好方法：能自动修的，多半是风格问题；不能自动修的，多半要认真看。

2.3 类型推断层：静态分析的善意揣测

在带有类型系统的语言里，黄色提示有相当一部分来自类型检查。以 TypeScript 为例，当你写了一个函数参数却没有标注类型，检查器会把它推断为 any，然后提醒你"参数隐式具有 any 类型"。这条警告在默认配置下不算错误，但开启严格模式后就会升级成红色。

类型警告的判定逻辑是：静态分析器沿着代码路径推导每个表达式的类型，当它无法确定类型、或者推导出的类型和声明不符、或者某个值可能为 null 却直接被访问属性时，就发出警告。这类警告的信息密度非常高，因为它往往指向运行时的空指针或类型错误。

举个最常见的场景：从接口拿到的数据，你觉得它一定有某个字段，直接访问，检查器提示"对象可能为 undefined"。新手的第一反应是加个感叹号或者类型断言把它压掉，代码立刻不黄了。但这条警告背后的事实是：网络请求可能失败，返回的数据可能缺字段，服务端可能改了结构。你压掉的是提示，不是风险。正确做法是加判断分支或者用可选链，让代码自己处理"拿不到"的情况。

我个人的经验是，类型类警告的修复投入产出比最高。它每一条几乎都对应一个真实的潜在崩溃点，改完不仅消除了黄色，还顺手把线上的偶发报错给堵了。所以如果时间有限，优先级排序应该是：类型警告 > 语义警告 > 编译警告 > 风格警告。

2.4 运行时与调试层：控制台里的另一套黄色

前面说的都是写代码时的静态提示，还有一类黄色出现在运行时——浏览器控制台或者终端日志里的 WARN 级别输出。这套体系和编辑器的波浪线没有关系，它是程序和框架在运行过程中主动打印的。

常见的几种：框架提示某个列表渲染缺少唯一标识、某个 API 已经废弃建议改用新写法、某个状态更新在组件卸载后执行可能有内存泄漏风险、某个资源加载失败回退到了默认值。这类警告的特点是场景相关性强，同一条警告在不同项目里含义可能完全不同。

处理这类警告要养成分清"谁打印的"的习惯。控制台输出通常带来源信息，如果调用栈指向第三方依赖的内部文件，那基本可以判定是库自身的问题，你能做的只有升级版本或者忽略；如果指向你自己的文件，那就要认真对待了。

还有一种黄色的来源经常被忽略——版本控制工具在比对文件时的差异标记。新增行是绿色，删除行是红色，修改行是黄色。有些新手在代码评审界面看到一大片黄色，以为代码有问题，其实是正常的内容变更标记。这个和代码质量毫无关系，认清楚就不会白紧张。

3. 从看到黄色到改干净：一套可复用的四步流程

3.1 第一步 定位：把提示信息拆成四段读

很多人看警告是扫一眼就动手，结果改了半天发现改错了地方。正确做法是先学会把一条提示读完整。一条规范的检查器提示通常包含四个部分：位置、级别、规则标识、说明文字。位置告诉你哪一行哪一列，级别告诉你严重程度，规则标识告诉你这条规则的名字或编号，说明文字告诉你具体问题是什么。

以常见的未使用变量提示为例，它的完整形态大致是：文件路径加行号列号，接一个警告级别标记，接规则编号，接一句"某某变量已被赋值但从未使用"。这里面信息量最大的是规则编号，因为它是可检索的，你可以拿它去查这条规则的详细定义和官方给出的修复建议。光看说明文字有时候会误解，因为同一句话在不同上下文里含义不同。

编辑器一般都提供了快速跳转的功能，可以按快捷键在文件内的所有问题之间循环跳转，不用自己滚动找。这个功能我强烈建议新手第一天就记住，它能把"漫无目的地找黄线"变成"跟着清单逐条处理"，效率差别非常大。

还有个小技巧：把鼠标悬停在波浪线上会弹出详细说明，很多时候弹窗底部还会有一个"快速修复"的链接。点开它，编辑器会列出几种可能的改法让你选。这不是让你无脑点第一个，而是让你看到工具认为有哪些可能的意图。看完这几个选项，你对这段代码本来该干什么的理解往往也会更清晰。

3.2 第二步 分级：三类标签的决策树

定位到了，接下来要决定改不改。我给新人用的判断标准是一个简单的三分类：

第一类，必须改。涉及类型可能为空、分支可能不返回、资源可能未释放、异步可能未捕获异常、安全相关的硬编码凭据。这些警告的共同点是：不改的话，某个特定条件下程序会崩，或者会泄露不该泄露的东西。这类没有商量余地。

第二类，应该改。未使用的变量和导入、重复的代码块、嵌套过深的判断、明显可以简化但写复杂了的表达式。这些不一定会出事，但它们会持续给后来读代码的人增加负担，而且修复成本通常很低。

第三类，可以不管。纯粹的格式偏好、行宽争议、某些主观性很强的命名规则、第三方依赖引发的告警、以及那些团队已经明确决定不启用的规则。这类直接通过配置关掉，比每次看到都纠结一遍要健康得多。

这个分级不需要精确，但必须做。因为不做分级的结果就是两种极端：要么全改，时间全耗在调格式上；要么全不改，真正的隐患被淹没。我在实际项目里的做法是，把第一类设成构建时的强制检查，改不完不让合并；第二类设成编辑器里的提示，什么时候看到什么时候改；第三类直接在配置里关掉。

3.3 第三步 修复：动手改的正确顺序

修复本身有个顺序问题，顺序对了能省一半时间。我的一般流程是：先改影响面大的，再改局部；先改能自动修的，再改要手动判断的；先改自己写的，再改别人的。

先改影响面大的，指的是优先处理那些会引发连锁警告的问题。比如一个函数的参数类型标注错了，可能导致函数体内十几处调用都亮黄。你把源头改对，那十几条警告自动消失。反过来如果一条条去改调用处，改到最后发现源头错了，全白干。

先改能自动修的，是因为自动修复不消耗你的判断力。格式、引号、分号、导入排序这些交给工具一键处理，处理完再看剩下多少条。这一步往往能把警告数量砍掉一大半，剩下的才是有价值的硬骨头。

先改自己写的，是因为你对那段代码的意图最清楚。别人写的代码，你看到一个"变量未使用"的警告，可能不敢删，因为不知道是不是预留的接口。这种情况下的正确做法是问，而不是猜。

还有一个操作上的注意点：改之前先提交一次。我踩过这个坑，一次性改了三十多处警告，改完发现程序跑不起来，想回退又不知道是哪一处改坏的，因为没有基线可以对比。分批次提交、每批改完跑一次测试，这个习惯能把排查成本压到最低。

3.4 第四步 治理：该关的关掉，该留的留下

改完一轮之后，真正重要的工作才开始：把规则配置固化下来，让它以后不再制造噪音。这一步做得好，团队里每个人每天都能少看几百条无意义的黄色。

治理的核心思路是分层配置。项目根目录放一份基础配置，定义所有人都必须遵守的规则集；个人可以在自己的编辑器配置里覆盖显示偏好，但不能覆盖严重级别。这样既保证了一致性，又保留了个性空间。基础配置里应该包含：启用的规则清单、每条规则的严重级别、哪些目录排除检查（比如构建产物、第三方代码副本）。

这里有个很实用的技巧：新项目从严格开始，老项目从宽松开始。新项目一开始就把规则开严，代码量小，改起来不痛苦，后面就一直是干净的。老项目已经有几千条警告了，一上来开严格模式会直接把人劝退，合理的做法是先关掉大部分规则，只留最关键的几条，然后定个规矩——新写的代码必须干净，老代码改到哪清到哪。这样警告总数会缓慢下降，而不是永远堆积。

还有一件事必须做：把检查挂到提交前的钩子和持续集成流程里。光靠编辑器里的波浪线，永远有人不看。挂在流水线上，不通过就不让合并，这才是真正能落地的约束。我见过太多团队，编辑器里配了一堆规则，实际合并代码时谁也不管，半年后规则形同虚设。

4. 高频黄色提示速查：三十条提示的修法对照

4.1 变量与作用域类

这一类是新手遇到最多的，也是最好处理的。核心判断标准只有一条：这个变量还有没有存在的必要。

表格里最后一行值得单独说。有些参数是接口约定要求必须有的，比如回调函数的第二个参数是索引，你不需要用它，但也不能删，因为位置是固定的。这种情况下的处理方式是用命名约定标记它是故意不用的，比如加个下划线前缀，并且写一句注释说明原因。压掉警告本身没错，错的是压掉之后没人知道为什么。

变量遮蔽那条我要再强调一次。这类警告的数量通常不多，但每一条都是潜在的定时炸弹。我在一个项目里遇到过这样的情况：外层有个index变量控制进度，内层循环又声明了一个index，内层循环结束后，后续代码用的还是外层的值，逻辑上看起来没错，但因为某次重构把两段代码合并了，内层的声明跑到了外层作用域，结果进度直接乱掉。排查花了两个小时，而当初那条警告就在那里挂了三个月。

4.2 类型与转换类

类型类警告的信息密度最高，值得逐条认真读。它们的共同特征是提示里会出现"可能为"、"隐式"、"不匹配"这类词。

// 警告：参数 item 隐式具有 any 类型 function formatItem(item) { return `${item.name} - ${item.price}`; } // 修法一：显式声明类型 interface Product { name: string; price: number; } function formatItem(item: Product) { return `${item.name} - ${item.price}`; } // 修法二：确实无法确定结构时，用 unknown 并做运行时校验 function formatItem(item: unknown) { if (typeof item !== 'object' || item === null) { return ''; } const obj = item as Record<string, unknown>; if (typeof obj.name !== 'string' || typeof obj.price !== 'number') { return ''; } return `${obj.name} - ${obj.price}`; }

这段对比很能说明问题。修法一只是在编译期给了个承诺，运行时如果数据真的不符合这个结构，照样会出错；修法二多写了十几行，但把"数据可能不符合预期"这件事真正处理了。新手往往会觉得修法二太啰嗦，但从工程角度看，边界数据的校验从来不是啰嗦，而是必需品。

另一类高频的是相等比较。松散相等会做类型转换，严格相等不会。检查器提示你改用严格相等，不是为了风格统一，而是因为松散相等的转换规则极其反直觉——空字符串和零相等、null 和 undefined 相等、字符串"0"和数字零相等。这些规则在写业务判断时是灾难，我见过因为用了松散相等导致权限判断被绕过的案例，那条警告当时就挂在那里。

还有空值访问。检查器提示"对象可能为 undefined"，正确做法是用可选链或者显式的判空分支。用非空断言强行压掉，本质上是在跟编译器打赌，赌这个值一定有。赌赢了没好处，赌输了就是线上崩溃。

4.3 异步与资源类

这一类是黄色提示里价值最高的部分，因为它们直接对应线上事故。异步类警告的核心场景是：发起了一个异步操作，但没有处理它失败的情况。

// 警告：Promise 未被处理，可能产生未捕获的拒绝 function loadConfig() { fetch('/api/config').then(res => res.json()); } // 修法：补上错误处理，并明确失败时的行为 async function loadConfig() { try { const res = await fetch('/api/config'); if (!res.ok) { throw new Error(`请求失败，状态码 ${res.status}`); } return await res.json(); } catch (err) { console.warn('配置加载失败，使用默认配置', err); return DEFAULT_CONFIG; } }

这段代码的关键差别不在写法，而在失败时的行为是否被定义。第一版里，请求失败就是一个没人管的拒绝，控制台会冒出一条黄色或红色的未捕获错误，程序其他部分继续跑，拿着 undefined 当配置用，然后在某个完全不相干的地方崩掉。第二版明确定义了失败降级策略，问题就被关在了这个函数内部。

资源类警告的典型代表是"监听器未移除"、"定时器未清理"、"连接未关闭"。这类警告在单次执行的脚本里几乎无害，但在长时间运行的界面程序里就是内存泄漏的源头。检查器能发现它们，靠的是分析注册和注销是否成对出现。修复方式很机械：在对应的清理逻辑里补上注销调用。麻烦的是找到"对应的清理逻辑"在哪，这需要你对代码的生命周期有清晰认识。

我个人的经验是，异步和资源这两类警告，宁可多花时间也不要压掉。它们的特点是"平时完全没问题，出事就是大事"，而且出事的时机往往在最糟糕的时候——流量高峰、长时间运行之后、用户操作最频繁的场景。压掉一条成本五秒钟，排查一次事故成本五小时，这笔账很好算。

4.4 工程与安全类

最后一类相对小众但对项目健康度影响很大。包括：硬编码的密钥和口令、过于复杂的函数、重复的代码块、注释掉的整段代码、调试输出语句残留、依赖版本冲突。

硬编码凭据这条，很多检查器会直接标成高危。新手觉得"本地测试用的，无所谓"，但代码一旦提交到共享仓库，这个凭据就等于公开了。正确做法是走环境变量或者配置中心，本地开发用一份不入库的配置文件。这条警告没有"可以不管"的选项。

函数复杂度的警告值得说两句。检查器通常用圈复杂度衡量，也就是函数里独立执行路径的数量。超过阈值就亮黄。新手的直觉是"能跑就行"，但复杂度高的函数有几个实际问题：测试用例数量会爆炸、改动时容易漏掉分支、读的人要在脑子里维护一堆状态。降低复杂度的常用手法是提取子函数、用提前返回消除嵌套、把复杂的条件判断抽成有名字的布尔函数。

注释掉的代码也常亮黄。有些人习惯把旧实现留着，觉得以后可能还要用。实际上版本控制工具已经把历史记下来了，留在源码里的注释代码只会让后来的人纠结"这段到底还有没有用"。删掉，需要的时候从历史里找，这是更干净的做法。

调试输出残留（比如打印语句）在很多团队里是禁止合并的。原因很实际：这些输出可能包含用户数据，可能在高频调用的路径上拖慢性能，也可能在正式环境里刷屏掩盖真正重要的日志。提交前扫一遍，成本很低。

5. 排查实录：那些"改了反而更糟"的坑

5.1 五个真实翻车场景

场景一：一键自动修复改坏了逻辑。有人对着整个项目点了自动修复，其中一条规则是"把松散相等改成严格相等"。大部分地方改完没问题，但有一处判断是拿接口返回的字符串和数字比较，原本靠类型转换能通过，改成严格相等后永远不相等，功能直接失效。教训是：自动修复要先看规则清单，涉及语义变化的规则不要批量应用，改完必须跑测试。

场景二：删掉"未使用"的变量，结果删掉了副作用。一段代码里有个变量赋值看起来没用到，删掉之后程序行为变了。原因是那个赋值表达式右边调用了一个会修改外部状态的函数，删掉赋值等于删掉了这次调用。这类情况检查器其实也给不出好建议，因为从语法上看它确实"未使用"。正确的处理方式是保留调用、去掉赋值部分，或者干脆写成独立的语句并加注释说明这是有副作用的调用。

场景三：压掉类型警告，线上白屏。一个列表页，数据从接口来时某个字段偶尔缺失，开发阶段测试数据都是全的，检查器提示"可能为 undefined"，被加了非空断言压掉。上线后遇到几条脏数据，页面直接崩。教训很直白：类型警告压掉的是检查，不是风险。

场景四：关掉全部警告，从此失去保护。有个项目因为警告太多，负责人在配置里把整个检查器禁用了。三个月后一次重构，改动了一个公共函数的返回结构，所有调用方都没有任何提示，上线后六个页面报错。如果检查器还在，这一改动会立刻引发几十条红色，一眼就能看出来。

场景五：不同工具的规则互相打架。格式检查工具要求每行不超过八十字符，另一个工具又要求某些语句必须写在一行内，结果那段代码怎么改都有一条黄。这种冲突的解法不是硬改，而是在配置里让其中一个工具忽略那类文件，或者调整阈值。工具是为人服务的，让工具打架是配置的问题，不是代码的问题。

5.2 团队协作中黄色提示不一致怎么办

这个问题的根源通常是配置没有入库。每个人本地装的插件版本不同、默认规则不同，同一个文件在不同人机器上黄的条数能差出一倍。解法很明确：把检查配置当成代码来管理，配置文件入库，版本锁定，所有人用同一份。

配套的还有编辑器的基础配置，比如缩进宽度、换行符类型、文件编码。这些东西不统一，跨平台协作时会制造大量无意义的差异——一个人在 Windows 上提交，另一个人在别的系统上拉下来，整个文件都显示成修改过，代码评审根本没法看。

再往上一层是流程。配置统一了，还得有执行机制。我的建议是三道关：编辑器里实时提示（自己看）、提交前钩子拦截（防手滑）、流水线强制检查（防绕过）。三道关里最重要的是第三道，因为前两道都可以被人为跳过。

还有个组织层面的经验：规则的制定要让实际写代码的人参与。如果规则是某个人拍脑袋定的，执行起来阻力会很大，大家会用各种方式绕。让团队一起过一遍规则清单，逐条讨论"这条我们要不要"，达成共识之后再写进配置，遵守率会高很多。

5.3 我自己的三条经验

第一条：新文件零警告，老文件不倒退。这是我在所有项目里坚持的底线。不去追求一次性把历史遗留的几千条警告清完，那不现实；但新写的每一行代码必须是干净的，改到的老代码顺手清掉。坚持半年，警告总数会自然降到可控范围。

第二条：每压掉一条警告，必须写一句为什么。压制本身不是错，错的是无声压制。我要求团队里所有压制注释都带上原因和责任人，比如说明这是接口约定必须保留的参数、或者这是已知的框架问题等待升级。这样半年后再看到这段代码，不会有人对着一行压制注释发呆。

第三条：把警告数量当成项目健康度指标看一眼。不用精确统计，就看趋势。如果某个模块的警告数在持续上涨，说明那块代码在快速劣化，值得安排时间整理一下。如果长期稳定在低位，说明这块代码维护得不错，可以放心改动。这个指标比代码行数有用得多，行数只说明规模，警告趋势说明质量走向。

最后分享一个具体的小习惯：每天开始写代码之前，先花两分钟把当前文件的警告清一遍，再开始写新功能。这个动作的成本极低，但它能让你在动手之前重新熟悉一遍这块代码的结构，顺带把昨天留下的尾巴收掉。我用这个习惯把警告清理从"一件需要专门安排时间的大事"变成了"顺手就做完的小事"，效果比任何一次集中整治都好。