技术纵深系列

多租户不是加个 tenant_id 就完了。共享表、独立 schema、独立库，三种模型的成本和失效方式不一样。这篇按 Spring Boot + MySQL 讲我怎么选、怎么落地，以及异步、定时任务、MQ、导出这些地方怎么漏。

一句“销售只能看自己的客户”，里面藏着行、列、入口、失效四个判定，RBAC 一个都答不了。这篇讲数据范围怎么落成一条 SQL、@DataScope 这类拼法会在哪一层漏、成本价为什么会整整齐齐出现在导出的 Excel 里，以及为什么详情接口是行级权限最大的口子。

需求说“要加门店”，开发在 sys_dept 上加了一列 type，两行代码当天上线。三个月后加代理商，type 多个值；半年后要求门店同时归区域运营、归总部核算，parent_id 只有一个。行政组织、经营单元、外部主体这三层的差别不在层级深浅，在于谁需要历史、谁会算钱、谁是外部人。

隔离模型选对了，租户条件仍然会从别的地方漏掉。缓存 key 少一段前缀，线程池里的上下文随着工作线程复用飘走，定时任务不带租户跑全表，搜索索引查询忘了 filter。八处的共同点不是层级深浅，是它们都绕开了你写好的那一层租户拦截器。按爆炸时间从上线第一天排到第一次月结。

订单状态那一列管得住“现在是什么”，管不住“谁把它改成的”“当时能不能改”“同一件事收到两次会怎样”。把 updateStatus(id, 3) 换成事件加守卫，改动量就是那十几处调用各自想清楚自己发的是哪个事件。

支付回调出错时不会报错。验签过了不等于认对了这一单，接口回了成功不等于账落了，退款受理不等于退成功，对账脚本解析出零行也照样返回成功。这些错全靠表结构和幂等键挡住。

余额字段一旦能被 update，账就只能靠人工对平。账户管谁是主体、流水管动了多少、凭证管为什么动，三张表各管一件事。分账规则要带生效区间，退款要按原分录反向冲销，可用和冻结别做成一行两列。代收再结算算不算二次清算，这条线绕不开。

只比渠道账单和我方订单，抓不到手续费漏记和分账记错。对账要能回答“错在哪一层”：渠道流水、业务订单、账户分录各对一次。下载地址 30 秒就失效、微信账单只给三个月、账单里的退款行出账后状态不再更新，而对账系统自己的失效方式是任务返回成功。

内网机器不给出网，最小化镜像里没有 CA 证书和中文字体，jar 里的 native 库只带 x86_64，镜像 tag 写成 latest 到了离线环境就是一个陌生的镜像名。“在我机器上跑通了”这句话在客户机房里不值钱，介质、环境检查、库结构、密钥、升级和回滚，每缺一样都能让安装卡在当场。

迁移项目开工第一天，客户发来一个压缩包，说数据都在里面。导进去只用了一个下午，财务发现上个月的应收少了一万二千七百八十八，用了三个星期才问明白差在哪。迁移的验收，说了算的是客户财务签字确认的金额、总量和权限范围；Excel 的合并单元格、期初余额、旧单号、离职员工，每一件都能让这个签字拖到下周。

凌晨一点半，客服在群里说“系统很卡”，这句话没法直接动手。要先把它拆成谁慢、哪个接口慢、从几点开始，才谈得上排查。200 QPS 的系统用不上重型 APM，但 traceId、四组指标和每条告警对应的 Runbook 缺一不可；这三样没有，监控大盘只是挂在墙上的屏保。

验收现场的顺序和开发时相反：客户不先点你讲了半小时的下单流程，而是拿出自己的 Excel 导一遍，再导出一张报表，最后打一张单。主流程决定系统能不能用，这三件事决定客户明天能不能上班；它们没有技术难度，只有工作量，报价里不写，后面就是免费加班。

直传、断点续传、秒传听起来是一个功能的三个阶段，其实是三个独立问题的三种解法：带宽绕行、大文件失败重来、重复文件不传。分清楚这三个问题，才知道自己的系统该先做哪个、哪个根本不用做。附各云厂商分片参数硬数字和一张 upload_task 表。

桶设成私有之后，前端怎么上传、怎么预览？答案是服务端签一条带时效的 URL 发给前端。签什么、有效期怎么定、拿什么凭证签，三件事里有两件和直觉相反。