银星皓月开工前，项目看板上躺着三张攒了两周的工单。2月15号这天，我一次性把它们全部清掉了，顺手在日报里写下“2.15完成105、106、110”。这行字看起来简单，但如果你手头也有那种“单个任务不复杂，凑在一起就让人头大”的积压工作，我的处理过程应该能给你一些参考。这篇就复盘一下这三个编号任务分别做了什么、怎么排序的、中途踩了哪些坑，以及事后觉得哪些做法值得保留。内容不限定在某一种语言或框架上，重点是思路和节奏，懂开发的都能直接借鉴。
1. 三个编号任务到底是什么：两个月积压下来的“小麻烦”
先交代一下背景，105、106、110是内部项目管理系统里的需求单号。它们不是那种需要立项评审的大项目，而是平时迭代中漏出来、被业务方反复催促但又不至于立刻停线的改造项。这类任务的共同特点是：单个拎出来半天能搞定，但如果一直拖着，就会在某个时间点集中爆发，催得你没法专心做新需求。
1.1 105号任务：订单查询接口慢查询优化
105号任务最直接，业务方反馈商户后台的订单列表页越用越卡，经常出现转圈十几秒才出数据的情况。查了监控，发现查询接口P95响应时间已经到2.1秒，数据库CPU在高峰时段接近70%。进一步定位，主要慢在订单主表和商户操作日志表的关联查询上，走了全表扫描，加上代码里循环查库，数据量上来之后性能直线下降。这个任务的核心诉求是：把P95响应压到500毫秒以内，同时降低数据库压力。
1.2 106号任务：第三方支付回调的兼容性改造
106号任务来自上游合作方。他们计划升级回调通知的签名算法和加密格式，但为了防止下游商户出现大面积回调失败，要求我们在切换期同时兼容旧版和新版两种报文格式。这个任务听起来不复杂，真正麻烦的地方在于协议文档描述含糊，对方只给了新版样例，没有明确说明旧报文会保留到什么时候，也没有给出切换开关的配置方式。我们需要自己设计一套双格式识别逻辑，还要保证在两种模式下都不丢单。
1.3 110号任务：导入功能的重复数据兜底校验
110号任务是运营后台的Excel批量导入导出的问题。运营人员手动录入数据时，界面上有重复校验提示，但通过批量导入接口上传时，系统只做了字段格式校验，没有做业务维度的唯一性校验。结果就是几个月下来，Excel里重复导入的商户或结算账户产生了大量“双份数据”，对账时怎么都对不上。任务要求是补全导入前的重复数据判断逻辑，并且把历史脏数据清洗掉，保证后续导入不会再次产生重复记录。
三个任务没有明显的前后依赖关系，但涉及的技术点互相独立，一个偏数据库性能、一个偏接口兼容、一个偏数据质量。把它们放在同一天处理，需要先想清楚顺序和精力分配，不然很容易出现“三件事都做了一半，哪件都没完成”的局面。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 开工前的排序策略：先做能立刻验证的，再啃需要外部响应的
很多人拿到多任务清单，第一反应是按编号顺序或截止时间排。我的习惯是按“验证成本”和“外部依赖”两个维度来排。
验证成本的意思是：做完这件事，你能否在短时间内确认它真的完成了？105号任务验证成本最低，因为性能指标非常明确，压测或者跑几条慢SQL日志就能知道结果；110号任务验证成本中等，需要造测试数据和准备Excel样张；106号任务验证成本最高，因为涉及第三方服务商，需要对方配合在测试环境推送新版回调报文，响应时间不受我控制。
外部依赖和上面类似，106号重度依赖第三方，110号依赖运营同事提供真实脱敏数据，105号完全自主可控。所以我的执行顺序是：
- 上午专注做105号慢查询优化，把性能指标打下来。
- 下午开始106号改造，但在改动之前，先给对方技术对接人发邮件，索取新版回调测试样例，把外部等待时间利用起来。
- 在等106号样例的同时，穿插做110号校验逻辑，因为这部分纯代码工作，不依赖外部环境。
这个顺序有个明显好处：上午先完成一个“有明确产出”的任务，后面心态会稳很多；最难等的外部响应被安排在下午，如果对方当天没回，至少110号已经完成，当天也不算白费。
3. 105号任务实录：从全表扫描到索引覆盖，一次慢查询的完整排除过程
105号任务处理的慢查询，表象是接口慢，实际原因有两层。第一层是SQL本身写得不够经济，第二层是ORM层循环查询放大了问题。光看慢日志只能定位第一层，第二层需要结合代码走查才能发现。
3.1 第一层问题：关联表缺索引导致全表扫描
慢日志里最刺眼的一条SQL是这样式的：
sql复制SELECT o.id, o.order_no, o.amount, o.status, l.operator_name, l.action
FROM orders o
LEFT JOIN orders_log l ON o.id = l.order_id
WHERE o.merchant_id = ?
AND o.create_time BETWEEN ? AND ?
ORDER BY o.create_time DESC
LIMIT 20
orders表本身有merchant_id和create_time的联合索引，但orders_log表只有order_id的普通索引。问题是orders_log表数据量已经到千万级，普通索引区分度不高，优化器在某些条件下会选择直接扫聚集索引。另外业务上有个隐藏逻辑：订单列表要展示最近一次操作记录，所以代码在查出20笔订单后，又循环执行了20次orders_log的查询，也就是经典的N+1问题。
我做了两件事：
- 给
orders_log的order_id字段改成覆盖索引，把operator_name、action、create_time这些查询列全部塞进索引里，减少回表次数。 - 把循环查库改成一次
IN查询，用订单ID列表一次性查回所有日志，在应用内存里做关联。
改完之后的SQL变成：
sql复制SELECT l.order_id, l.operator_name, l.action, l.create_time
FROM orders_log l
WHERE l.order_id IN (...)
AND l.create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)
在测试环境模拟了300万订单日志数据，单次查询从2.1秒降到80毫秒左右，数据库CPU在压测过程中没有明显飙升。这里有个容易被忽略的点：为什么IN查询不加ORDER BY？因为最终排序仍然以订单列表的create_time为准，日志数据的顺序在内存中重组，不需要让数据库额外执行一次排序。
3.2 第二层问题：生产环境和测试环境数据分布差异
测试环境通过之后，部署到生产还需要谨慎一点。这里我踩过类似坑，奉劝大家不要直接照搬测试环境索引到生产。生产环境的订单日志表，数据分布不像测试那么均匀，某些热门商户的日志量远超平均，单独跑EXPLAIN大概率没问题，但一上真实流量可能就暴露问题。
我的做法是：先在预发环境开启慢查询日志，用影子流量回放一部分线上请求，观察新SQL的执行计划和响应时间分布。影子流量跑了20分钟，确认没有慢查询记录后，才在生产环境执行索引创建。注意，在大表上建索引会锁表或锁行，需要用pt-online-schema-change这类在线变更工具，或者选择业务低峰期窗口执行。我是安排在凌晨2点由DBA执行的，全程耗时约40秒，没有影响线上读写。
改完之后的对比数据如下：
| 项目 | 优化前 | 优化后 |
|---|---|---|
| P95响应时间 | 2130ms | 96ms |
| 接口平均响应 | 1250ms | 58ms |
| 数据库CPU峰值 | 68% | 21% |
| 单接口IO次数 | 21次 | 2次 |
这组数据报上去，105号任务就算闭环了。但我要多说一句，性能优化从来不只靠一个索引，后续还要定期关注慢查询日志，防止新需求引入新的低效SQL。我习惯在监控面板上单独拉一个“慢SQL趋势”图，超过阈值自动告警。
4. 106号任务复盘：第三方回调新旧格式兼容的隐蔽坑
106号任务本身是配合第三方服务商做协议升级。对方通知说，新的回调报文将启用AES-128-GCM加密，旧的RSA加密报文会在未来三个月内逐步下线。问题在于对方已经切换了一部分流量，所以系统必须在同一时刻支持两种报文解析，不能简单粗暴地“换新的，弃旧的”。
4.1 先明确协议识别策略：从报文头判断而不是靠异常兜底
兼容方案的核心不是先尝试解析再捕获异常，而是主动识别报文类型。我看了新旧样例，发现新版报文在外层JSON中多了一个cipher_version字段，值为2；旧版报文没有这个字段。所以我设计的解析入口是这样的：
javascript复制function parseCallback(rawBody) {
const envelope = JSON.parse(rawBody);
if (envelope.cipher_version === '2') {
return decryptAESGCM(envelope.cipher_text, aesKey);
}
// 默认走旧版RSA解密逻辑
return decryptRSA(envelope.cipher_text, rsaPrivateKey);
}
先判断协议版本，再走对应的解密分支，这是一个很朴素的策略，但避免了一个大坑：不要等解密失败抛异常再切换逻辑，因为AES-GCM和RSA的解密失败表现完全不同，AES-GCM对密钥和IV非常敏感，一旦错位会直接抛认证失败异常，而RSA解密由于填充机制，偶尔会出现“能解出来但内容乱码”的情况，你用异常兜底根本拦不住乱码数据入库。
4.2 解密失败后的兜底：丢进重试队列而不是直接报错
双协议兼容的另一个关键是失败处理。我在回调入口加了重试机制：任何解密或验签失败的回调，不直接返回失败给第三方，而是记录到本地重试表，同时返回HTTP 200给第三方。这么做的原因是，第三方服务商的回调超时重试策略很激进，如果系统返回非200响应，对方会立刻重试，短时间内会打来几十个相同请求，反而增加处理压力。
重试表里的数据由定时任务每5分钟扫描一次，排除人工干预的异常记录，最多重试3次，超过3次的进入人工死信表。这条路在双协议切换期非常重要，因为总会有部分报文因为密钥版本没同步而解密失败，有一个兜底队列能避免丢单。实际运行中，重试表里确实累积了千分之一左右的失败记录，基本都是新旧密钥轮换期间的正常现象，没有一条最终丢失。
4.3 离线重放场景也要纳入兼容范围
106号任务还有一个隐蔽需求，是测试过程中发现的。对方在切换期会重新推送过去48小时内部分订单的回调报文，用来保证遗漏订单能补上。这就意味着系统不仅需要处理实时回调，还需要接受“重复通知”的幂等场景。我们在处理逻辑里增加按业务单号去重的判断，重复报文直接返回已处理状态，不会二次触发业务流转。
这个点提醒我，涉及第三方系统的兼容性改造，不能只看“怎么接收新数据”，还要看“旧数据会不会以某种形式重放”，最好提前和对方确认消息语义是at-most-once还是at-least-once。我们的重试表和幂等表就是为了适配at-least-once场景，目前线上运行稳定。
5. 110号任务：导入校验的边界条件，从源头堵住重复数据
110号任务看起来是最“业务”的一个，但真正写起来才发现里面的边界情况相当多。需求背景是运营后台支持Excel批量导入商户结算账户，原逻辑只校验了字段格式，比如手机号11位、金额为正数、日期格式正确，但没有判断“这批Excel里的数据，在数据库里是不是已经存在了”。导致运营拿到一份包含重复账户的Excel时，系统会把所有行都导入成功，包括重复行。
5.1 重复定义的三个层次：完全相同、忽略空白、大小写归一化
在设计校验逻辑时，我先和运营确认了“什么是重复”。表面看，手机号或银行账号相同就算重复。但Excel里经常有隐藏空格、大小写不一致、中文全角半角混用的情况。所以我设计了三个层次的重复判断：
- 第一层：完全匹配，数据库中已存在完全相同的值，直接判为重复。
- 第二层：忽略字符串两侧空白后匹配，例如
"13800138000 "和"13800138000"视为重复。 - 第三层：大小写归一化后匹配，比如邮箱或商户编号
ABC001和abc001视为同一账户。
判断逻辑统一写在一个校验服务里，导入接口和手工录入接口共用这套规则，避免两套逻辑以后越走越远。
python复制def normalize_key(value: str) -> str:
return value.strip().lower()
在批量导入场景中，还有一个Excel文件内部自身的重复判断。比如同一张表里出现两行完全相同的账户，不一定要等写库的时候靠唯一索引报错，而是在预检阶段就一次性列出来，告诉运营“第7行和第23行重复，请处理后重新上传”。
5.2 批量导入的预检机制：先全量检查再落库
运营后台导入的数据量通常是几千行到几万行不等，不可能一行校验通过就立即写库。我的设计是两步走：
- 上传文件后先做全量预检，逐行执行格式校验、业务规则校验、重复校验，统计所有问题和对应行号。
- 只有当所有错误行数为0时，才允许执行导入；导出的错误文件中，以sheet页形式展示每行错误的具体原因。
这样做对运营人员更友好，也避免“导入到一半因为某条脏数据导致整体回滚”的情况。全量预检的实现需要注意内存管理：几万行数据量不大，但如果Excel里还有几十列的大宽表，直接用Pandas读取还好，再用ExcelWriter写回错误标注时要注意单元格样式不能太多，否则文件体积会膨胀到几十MB，导致下载超时。我最后采用了分批读取和写出的方式，每5000行处理一次，错误文件控制在5MB以内。
5.3 历史脏数据清洗的折中方案
除了拦截新增重复数据，需求还要求处理历史脏数据。这一步比新增校验更敏感，因为直接删数据是有风险的业务操作。我的方案是：先跑一个统计脚本，把疑似重复的账户ID、重复次数、关联的结算记录数和首次导入时间列出来，交付给运营和财务确认。确认无误后，不物理删除，而是给重复记录打上is_duplicate=1标记，在正常业务查询中默认过滤掉，保留数据审计追踪能力。这是很多清洗任务里比较稳妥的“软删除”做法，避免一删了之之后无法回溯。
清洗脚本执行了约10分钟，找出重复账户147组，涉及358条重复记录。运营确认后，其中112组保留最早的一条作为主记录，剩余标记为重复。整个过程有完整操作日志，可以回溯每一次清洗动作，也方便出问题的时候回滚。
6. 穿插执行的两点经验：顺序与专注度
105、106、110三个任务在2月15日当天完成，但从过程来看，我并不建议所有人效仿“一天三个任务”这种节奏。更准确地说，这三件事的分量都不是“五分钟热修”级别，每件都需要写代码、测试、跟进，能顺利并行，靠的是合理的穿插和边界控制。
6.1 利用外部等待的“时间缝隙”
106号任务发出去等待第三方样例的间隙，我并没有盯着聊天工具干等，而是切到110号的校验开发。因为110号任务不依赖任何外部联调环境，完全是本地开发加单元测试就能推进的。在等待期间，我写完了normalize_key函数和重复校验服务，并准备好了测试Excel文件。
这个经验不算高深，但很多人执行时容易忽略：碎片时间要交给“上下文切换成本低”的任务。110号这种逻辑明确、测试方法清晰、不依赖他人的任务，适合见缝插针；105号这种需要观察监控数据、分析执行计划的任务，适合大块专注时间。106号则可以把“写代码”和“等响应”拆开，写代码不等人，但联调必须等。
6.2 一天内切换多个任务的状态保持技巧
每个任务开发时，我会在项目里建一个docs/todo目录，放一份简要的进度笔记，记录当前做到哪一步、待办是什么、下次继续时需要回忆哪些上下文。比如105号的笔记里会写“测试环境索引已验证，生产索引待DBA执行”；106号会写“代码完成，等待对方提供新报文样例”；110号会写“预检逻辑单测通过，准备提交联调”。
这样做的原因是，即使项目管理系统里有详细描述，等你切回某个任务时，脑子里的指令缓存早就失效了。花30秒写一条进度备注，能省下回来之后半小时的重新阅读和回忆时间。
7. 收尾验收：代码完成不代表任务结束，还有三件事要做
三个任务都写完代码，不代表工单可以直接点了“完成”。我会按照固定流程做收尾验收，这个流程帮我避免过很多次“开发觉得没问题、上线就出问题”的事故。
7.1 先用接口测试脚本过一遍核心链路
每个任务我都会配上专门的接口层测试，而不是只跑单元测试。比如105号，优化后虽然查询变快了，但接口返回的数据格式不能变，测试脚本验证返回的字段、排序、分页参数都和原来一致；110号，要验证重复导入时提示语明确，错误文件能正常下载；106号，验证新旧两种报文都能正确解密并触发后续流程。这里有一个细节：如果团队没有自动化接口测试平台，本地用Postman或者Python脚本先模拟一遍核心链路也可以。
7.2 拉一次代码评审，重点看边界分支
代码评审不是走形式。我的习惯是主动约另一位同事做一次简短的评审，让他重点看异常分支和边界条件。这次评审确实帮106号抓到一个问题，早期版本里新旧报文都带上cipher_version=2时，解密分支会继续往下走，重复解密同一份密文会导致GCM认证失败。虽然实际场景中对方不太可能犯这种错误，但代码还是主动加了非空判断和单个字段的二次确认。
评审中还有一个值得记录的讨论点：新版报文解密失败时，错误日志里不能打印完整的密钥或原文蜜文，只允许打印前4位和后4位的散列值，减少敏感信息泄露风险，这条后面也更新到了团队的日志规范里。
7.3 回归测试不要漏掉旧链路
任何兼容性改造，最大的风险是旧功能被意外破坏。106号的回归测试清单包括：旧版云短信回调、旧版密文保存、管理后台历史报文查询、按单号重试，等等。我专门让测试同事跑了全量回归用例，重点看支付订单状态流转这类核心路径。105号的回归则是拉取线上最近一天的订单数据，随机抽了100个商户ID，逐个请求接口，比对返回结果的业务字段是否与优化前一致。
回归测试这一环节，正好也是对工单任务里“完成”标准的对齐。我理解的“完成”，不是开发环境自己点了通过，而是从开发到测试、到功能验证、到上线后监控观察，整个链路都走完，才算真正完成。所以2.15当天，其实当天晚上我还在看生产日志，确认105号的慢SQL没有回潮、106号的重试表为空、110号没有产生新的重复数据告警，然后才安心在任务列表里划上勾。
8. 关于“一天完成三个任务”的诚实复盘
写这篇稿子的时候，我重新翻了一下2月15号那天的排期和记录，想诚实地复盘一下这样做到底值不值得。
8.1 收益：节奏感和可见产出
最直接的收益是，三张工单从“积压”变成“已交付”，业务方和项目管理同事看到日报时的信任感明显增强。105号的性能数据，让商户后台的实际操作者感觉“卡顿消失了”；110号上线后，运营再也没来质问为什么同一个账户能在系统里出现两次；106号虽然晚一点才完全切换新版，但至少切换期间没出现回调丢失。
从团队协作角度讲，一次交付多个任务，也减少了后续评审和同步的碎片时间。所有任务的状态变更、测试记录、上线说明集中在一个时间段，沟通成本相对更低。
8.2 代价：对精力的透支不能常态化
但我也要诚实说，一天处理三个任务确实很累。105号需要看监控、查执行计划、调索引，属于重度脑力工作；106号需要反复确认文档、写兼容逻辑，属于细节敏感型工作；110号虽然难度不大，但测试用例准备和回归验证需要耐心。一天之内做完这么多事，下午后半段明显感觉反应速度下降。
所以我的结论是：偶尔一次集中清积压没问题，但要避免每周都靠这种方式赶工。更健康的状态是，每天或每两天消化一个中型任务，让任务管理看板长期保持在一个“略有压力但不断档”的水位线上。
8.3 后续可复用的经验清单
如果把这些经验压缩成几条，方便以后直接参考：
- 多任务并行时，先做有明确完成指标的任务，再做依赖外部的任务，把等待时间变成碎片任务的执行窗口。
- 涉及性能优化，不能只信测试环境数据，还必须考虑生产数据分布和变更窗口。
- 涉及协议兼容，优先通过报文显式识别新老版本，而不是靠解密异常切换逻辑。
- 涉及数据清洗，“软删除”加审计日志往往比物理删除更安全，也能减少业务风险。
- 每个任务留一个进度备注，切换任务时能省下大量重新理解上下文的时间。
- 收尾验收比开发更重要，接口实测、代码评审、回归测试三条腿缺一不可。
2月15号只是一个普通的工作日。但这三个编号任务一口气清完的经验，让我对“多任务管理”这件事有了更实际的体会：不是靠加班堆时间，而是靠排序、节奏和边界控制把碎片拼成完整交付。如果你手上也有一批积压的中小型任务，希望这篇复盘里面的排查链路和排序策略能帮你少踩几个坑。