技术沉淀

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

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

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

做过的项目里，小单子反而最考验工程能力。大项目有预算、有时间、有架构组；一个两三周交付的小站、一个小程序，预算往往只够你做对三件事。 所以我给自己的规矩是：先把三件事做对，剩下的都可以妥协。 第一件：数据模型别急着设计 我现在的习惯是先上线，再补抽象。小项目的需求变化快，过早设计出来的模型，九成会在

一个 RAG 的演示，准备二十个问题，答对十九个不算难。文档切好，向量存进去，提示词里写一句“只根据资料回答”，看起来就能用了。接进业务系统的第一周，问题通常不在答得准不准。客户问“我们门店的退货规则”，它把另一个门店的制度答了出来，语气还很确定，后面还带了一句“如有疑问请联系客服”。这句话在演示里

※ 本文写于 2026-10-20，当时用的还是 Fly 主题。本站现已换成 Cosolar，同一个坑换主题后一模一样：主题配置的 ConfigMap 从未保存过，theme.config 为 null，首页模块全部不渲染。下面这套排查方法对现在的站依然有效。

如果你看到了这一篇文章，那么证明你已经安装成功了，感谢使用 Halo 进行创作，希望能够使用愉快。