技术沉淀·
文件和异步链路上，上线后才暴露的几处漏洞功能测试都过了，为什么上线后还是出事？因为测试覆盖的是有人操作的路径，而文件和异步的漏洞全藏在没人操作的地方：中断、重复、积压、静默。六处逐一给防线。
技术沉淀·
AI 功能接进业务系统的三种边界客户说「加个 AI」，先别急着做自动化。AI 接进业务系统只有三种形态——旁路只读、助手确认后执行、自动化直接执行，三者在权限、审计、回滚上的成本完全不同，从旁路起步。
技术沉淀·
延迟任务：超时关单、定时提醒的三种实现超时关单、预约提醒这类「到点才做」的任务，实现不外乎三种：数据库扫表、MQ 延迟消息、Redis ZSet。先分清业务要准时还是要不丢，选型就不会摇摆。
技术沉淀·
对象存储：目录、权限、生命周期对象存储里没有文件夹，「目录」只是 key 的前缀；前缀定了，权限和生命周期才挂得上去。这篇给一套前缀规划、按前缀授权的写法，和一笔生命周期规则的经济账——配错规则的罚金比省下的钱多。
技术沉淀·
文件上传：直传、断点续传、秒传各解决什么直传、断点续传、秒传听起来是一个功能的三个阶段，其实是三个独立问题的三种解法：带宽绕行、大文件失败重来、重复文件不传。分清楚这三个问题，才知道自己的系统该先做哪个、哪个根本不用做。附各云厂商分片参数硬数字和一张 upload_task 表。
行业观察·
行业系统做成白牌，先看领域模型能不能复用很多团队以为白牌就是换 logo、换配色、换菜单，把定制项目包装成产品再卖一遍。真正决定第二单能不能赚钱的，是领域模型、流程、接口、合规这四层能不能复用。这篇讲怎么在接单之前判断，以及为什么先做交付包比先做官网更重要。
行业观察·
蓝领招工难在实名和日结蓝领招工系统的功能列表和白领招聘长得差不多，真正难的是另外两件事：来的人是不是他本人，干完这一天钱怎么发出去。实名、考勤、日结、四流一致，每一件都同时是技术问题和合规问题。这篇讲这四个环节在代码里长什么样，以及平台该站在哪个位置。
行业观察·
多商户商城的库存，为什么不能挂在订单上商城的第一版，库存通常长在商品表上，结算状态挂在订单上。二十个商户、几百个 SKU 能跑过验收，第一次大促就会同时出现超卖和对不上账——锁救不了它，根子在五个域被压进了同一两张表。这篇按商品、库存、订单、履约、结算的顺序，讲每个域该拥有什么，边界又该落在哪几张表上。
技术沉淀·
主流程演示得再顺，客户还是要先导一个 Excel验收现场的顺序和开发时相反：客户不先点你讲了半小时的下单流程，而是拿出自己的 Excel 导一遍，再导出一张报表，最后打一张单。主流程决定系统能不能用，这三件事决定客户明天能不能上班；它们没有技术难度，只有工作量，报价里不写，后面就是免费加班。
技术沉淀·
线上出问题，先分清是所有人都慢还是一个人慢凌晨一点半，客服在群里说“系统很卡”，这句话没法直接动手。要先把它拆成谁慢、哪个接口慢、从几点开始，才谈得上排查。200 QPS 的系统用不上重型 APM，但 traceId、四组指标和每条告警对应的 Runbook 缺一不可；这三样没有，监控大盘只是挂在墙上的屏保。
技术沉淀·
RAG 接进业务系统，权限和评测绕不过去演示阶段准备二十个问题，答对十九个不难；接进业务系统之后，真正会出事的是它把另一个租户的制度答了出来，语气还很确定。RAG 的工程难点不在模型，在检索前的权限过滤、文档版本和删除的同步、一套从真实工单里长出来的评测集；Agent 再往前走一步，写操作必须停下来等人确认。
技术沉淀·
数据迁移完了，没人敢关旧系统迁移项目开工第一天，客户发来一个压缩包，说数据都在里面。导进去只用了一个下午，财务发现上个月的应收少了一万二千七百八十八，用了三个星期才问明白差在哪。迁移的验收，说了算的是客户财务签字确认的金额、总量和权限范围；Excel 的合并单元格、期初余额、旧单号、离职员工，每一件都能让这个签字拖到下周。
技术沉淀·
私有化部署的最小交付包，拔掉网线还能装起来才算内网机器不给出网，最小化镜像里没有 CA 证书和中文字体，jar 里的 native 库只带 x86_64，镜像 tag 写成 latest 到了离线环境就是一个陌生的镜像名。“在我机器上跑通了”这句话在客户机房里不值钱，介质、环境检查、库结构、密钥、升级和回滚，每缺一样都能让安装卡在当场。
技术沉淀·
账不平时要能说出错在哪一层只比渠道账单和我方订单，抓不到手续费漏记和分账记错。对账要能回答“错在哪一层”：渠道流水、业务订单、账户分录各对一次。下载地址 30 秒就失效、微信账单只给三个月、账单里的退款行出账后状态不再更新，而对账系统自己的失效方式是任务返回成功。
技术沉淀·
分账的账要能倒推回去余额字段一旦能被 update，账就只能靠人工对平。账户管谁是主体、流水管动了多少、凭证管为什么动，三张表各管一件事。分账规则要带生效区间，退款要按原分录反向冲销，可用和冻结别做成一行两列。代收再结算算不算二次清算，这条线绕不开。
技术沉淀·
支付回调出错时系统一声不吭支付回调出错时不会报错。验签过了不等于认对了这一单，接口回了成功不等于账落了，退款受理不等于退成功，对账脚本解析出零行也照样返回成功。这些错全靠表结构和幂等键挡住。
技术沉淀·
多租户系统最容易出事的 8 个位置隔离模型选对了，租户条件仍然会从别的地方漏掉。缓存 key 少一段前缀，线程池里的上下文随着工作线程复用飘走，定时任务不带租户跑全表，搜索索引查询忘了 filter。八处的共同点不是层级深浅，是它们都绕开了你写好的那一层租户拦截器。按爆炸时间从上线第一天排到第一次月结。
技术沉淀·
订单状态机：别用 status=1,2,3 糊弄订单状态那一列管得住“现在是什么”，管不住“谁把它改成的”“当时能不能改”“同一件事收到两次会怎样”。把 updateStatus(id, 3) 换成事件加守卫，改动量就是那十几处调用各自想清楚自己发的是哪个事件。
技术沉淀·
部门、门店、代理商，一张 sys_dept 表撑不住这三层需求说“要加门店”，开发在 sys_dept 上加了一列 type，两行代码当天上线。三个月后加代理商，type 多个值；半年后要求门店同时归区域运营、归总部核算，parent_id 只有一个。行政组织、经营单元、外部主体这三层的差别不在层级深浅，在于谁需要历史、谁会算钱、谁是外部人。
技术沉淀·
权限系统：RBAC 不够用的地方，数据权限怎么补一句“销售只能看自己的客户”，里面藏着行、列、入口、失效四个判定，RBAC 一个都答不了。这篇讲数据范围怎么落成一条 SQL、@DataScope 这类拼法会在哪一层漏、成本价为什么会整整齐齐出现在导出的 Excel 里，以及为什么详情接口是行级权限最大的口子。
技术沉淀·
多租户不是加一个 tenant_id：三种隔离模型与选型多租户不是加个 tenant_id 就完了。共享表、独立 schema、独立库，三种模型的成本和失效方式不一样。这篇按 Spring Boot + MySQL 讲我怎么选、怎么落地，以及异步、定时任务、MQ、导出这些地方怎么漏。
该分类下暂无文章