电商后台管理系统从0到1：需求、架构、数据库与核心链路实战

“电子商务网站后台管理系统”这几个字，几乎是每个做企业级开发的人都绕不过去的项目。有人拿它练手，有人拿它交付，也有人做了三四年还在往里面加功能。我从最早写增删改查页面，到后来负责整套后台的架构和迭代，前后经手过好几个不同规模的版本，踩过的坑能写满一个笔记本。今天我不打算讲那些大而空的“系统概述”，而是把从需求拆解、架构选型、数据库设计，到权限控制、库存扣减、订单流转、线上排障的完整过程摊开讲一遍。这篇内容适合三类人看：刚接触后台开发、想知道一个能上线的系统该长什么样的新手；做过几个模块、但没从零搭过整体结构的中级开发者；以及负责技术方案、需要判断哪些设计值得投入的人。全文会给出可以直接抄的表结构、关键SQL和代码片段，也会讲清楚每个选择背后的取舍理由，看完你至少能少走半年弯路。

1. 需求拆解：后台系统到底在管什么

1.1 前台与后台是两套完全不同的逻辑

很多人一开始会把后台管理系统理解成“前台页面的管理版”，这个认知偏差会直接导致后面架构跑偏。前台的核心诉求是“让用户看到商品并顺利下单”，它的优化方向是响应速度、转化率、页面渲染；而后台的核心诉求是“让运营人员准确、安全、可追溯地改动数据”，它的优化方向是权限边界、操作审计、批量处理能力和数据一致性。

举个很具体的例子：前台查商品，只需要拿到上架状态、价格、库存、主图这几个字段，查询走缓存，一秒内返回就行；后台查商品，运营要按类目、品牌、价格区间、上架状态、创建时间、库存阈值做组合筛选，还要分页、导出、批量改价、批量上下架。这两个场景对数据库的压力完全不在一个量级。我见过有项目为了省事，后台直接复用前台的查询接口，结果运营一导出三万条商品数据，前台接口直接超时报警。

所以设计的第一步，是把两类角色和两类数据流彻底分开。后台面对的是内部员工，人少但操作重；前台面对的是外部用户，人多但单次操作轻。想清楚这一点，你才会理解为什么后台需要独立的权限体系、独立的路由、甚至独立的数据库读库。

1.2 把口头需求翻译成功能清单

真实项目里，需求往往是一句话：“给我做个能管商品、管订单、管人的后台。”这句话要变成可开发的功能点，中间需要一轮结构化拆解。我的习惯是按“对象—动作—约束”三个维度列表，先把对象找全，再列动作，最后补约束。

这张表看着简单，实际价值极高。它把“要做什么”固定下来，后面写接口、建表、排期都围绕它走。我特别建议在表里加一列“优先级”，标注哪些是第一版必须有的，哪些可以放到二迭代。真实的项目延期，八成不是因为技术难，而是因为范围没锁死，需求一路膨胀。

还有一个容易被忽略的点：约束条件往往比功能本身更重要。比如“有商品的类目不能删”，这条约束如果不在设计阶段明确，等到上线后运营误删了一个类目，几万条商品全部丢失分类，那才是真正的灾难。所以我在做需求拆解时，会把每条约束都对应到一个具体的校验点，是前端拦、后端拦，还是数据库外键拦，提前定好。

1.3 角色决定菜单，而不是反过来

后台的菜单结构不应该拍脑袋画，它应该由角色推导出来。一个典型的电商后台至少有这几类角色：超级管理员、运营、客服、仓储、财务。每类角色关心的东西完全不同。

运营天天泡在商品和营销活动里，需要商品管理、优惠券、活动配置；客服主要处理订单查询、退款审核、用户投诉，需要订单和会员模块，但不需要看到成本价；仓储只关心待发货订单、库存数量、物流单号录入，给他看财务数据纯属干扰还容易出事；财务要的是对账单、退款流水、结算记录，权限必须严格隔离。

我一般的做法是先把角色列出来，再画一张“角色—菜单”的矩阵表，打勾确认。这张表直接就是后面RBAC权限初始化的数据来源。好处是权限设计有据可依，不会出现“这个菜单给谁看”的扯皮；坏处是要花的沟通时间不少，但绝对值得。等系统上线后再补权限，成本会翻好几倍，而且极容易漏。

2. 架构与技术选型：按团队规模倒推，而不是按流行度

2.1 单体优先的判断依据

每次聊到后台系统架构，总有人上来就问“要不要上微服务”。我的答案很直接：看团队规模和迭代节奏，不看技术热度。一个后台管理系统，日活内部用户可能就几十个，QPS 峰值撑死几百，这种量级上微服务，收益几乎为零，成本却高得吓人——服务拆分、注册中心、链路追踪、分布式事务、多套部署脚本，每一样都要人维护。

我经手过一个典型的反例：某团队五个人，做一套电商后台，一开始就拆成了商品服务、订单服务、用户服务、库存服务四个模块，各自独立部署。结果一个“下单扣库存”的流程，跨了三个服务，为了保一致性引入消息队列和补偿逻辑，光调试分布式事务就花了三周。后来业务方要加一个“订单列表带商品信息”的需求，又得做服务间聚合查询，接口响应从 80ms 涨到 400ms。最后他们又花了一个月合并回单体。

我的判断标准是这样的：团队少于十人、业务模块之间没有独立伸缩需求、没有独立的发布节奏要求，那就老老实实做单体，用清晰的包结构做逻辑分层。等哪天真到了瓶颈，再按模块拆，代码结构清晰的话，拆起来并不难。反过来，一开始就拆散，想合回来才是真的痛。

单体内部的包结构我一般这么分：controller只做参数校验和响应封装，service承载业务逻辑和事务边界，mapper或repository只管数据访问，domain放实体和值对象，common放统一响应、异常、工具类。分层清晰比架构花哨重要一百倍，因为后台系统的代码是要长期维护的，接手的人能不能三分钟看懂一个接口的调用链，直接决定维护成本。

2.2 技术栈组合与每个选择的理由

后台管理系统的技术选型，核心原则是“成熟、好招人、文档全”。我常用的组合是：后端 Java + Spring Boot + MyBatis-Plus，数据库 MySQL，缓存 Redis，前端 Vue 3 + Element Plus，反向代理 Nginx，定时任务用 Quartz 或框架自带的调度。下面说说每个选择背后的考虑。

这里我要特别强调 ORM 的选择。后台系统最大的特点就是复杂条件查询多，运营提的筛选条件经常是七八个字段任意组合。用全自动的 ORM，遇到这种场景要么写一堆动态条件构造器，要么退化成拼字符串，反而更难维护。MyBatis-Plus 的好处是既能用它的条件构造器处理常规查询，又能随时写原生 SQL 处理复杂统计，灵活度刚好。

另外一个常被忽略的选型是参数校验和统一异常处理。我习惯在项目初始化阶段就把这块搭好，用注解做基础校验，用全局异常处理器统一捕获业务异常和系统异常，返回结构化错误码。这件事花不了半天，但能省掉后面无数个“接口报 500 但不知道哪出错”的排查时间。

2.3 接口规范与统一响应结构

后台系统前后端分离之后，接口就是双方的契约。契约不统一，后面每加一个接口都要重新对齐一次，非常消耗。我的做法是在项目第一天就定死响应结构和错误码规范，所有人都按这个来。

统一响应体一般长这样：包含业务码、提示信息、数据体、时间戳。业务码约定好区间，比如 0 表示成功，1 开头是通用错误（参数错误、未登录、无权限），2 开头是业务错误（库存不足、状态不允许），5 开头是系统错误。这样的好处是前端可以按码段做统一处理，比如遇到 401 直接跳登录页，遇到 403 弹无权限提示，不用每个接口单独判断。

分页参数也要统一。我一般固定用页码加每页条数两个参数，且后端必须对每页条数做上限限制，比如最大 100 条。这个限制看起来不起眼，实际上是防事故的关键一环——没有它，某个前端同学随手传个一千，数据库直接被打穿。类似的防御性设计还有不少，比如排序字段必须走白名单，绝不能把前端传来的字段名直接拼进 order by，那是注入漏洞的温床。

3. 数据库设计：后台系统的地基

3.1 商品模型：SPU与SKU怎么分

商品模型是整个后台最容易设计翻车的地方。新手常见做法是一张商品表搞定，字段里塞颜色、尺码、价格。做到一半就会发现：一件衣服有红蓝两色、S/M/L 三个码，六个组合价格可能不同、库存各自独立，一张表根本装不下。正确做法是分成 SPU 和 SKU 两层。

SPU 是标准产品单元，代表“这是什么商品”，比如某款 T 恤；SKU 是库存量单位，代表“具体哪个规格可卖”，比如红色 M 码。用户下单买的是 SKU，运营管理的列表展示的是 SPU，这是两个视角。表设计上，SPU 表存标题、类目、品牌、描述、上下架状态；SKU 表存规格组合、价格、库存、图片、编码，并且通过 SPU 主键关联。

这里有个坑我踩过：规格属性不能写死在字段里。今天加颜色，明天加尺码，后天加材质，字段一路加下去表就废了。正确做法是单独设计属性表和属性值表，SKU 与属性值做关联，这样新增规格只是加数据，不用改表结构。这套设计稍微复杂一点，但扩展性天差地别。

价格字段也值得单独说。金额绝对不能用浮点数存，这是铁律。浮点数在二进制下无法精确表示小数，0.1 加 0.2 不等于 0.3，累加几百笔订单后误差会放大到肉眼可见。我一般用定点小数类型存元，或者更稳妥一点，用整数存“分”，展示时再除以一百。前者简单直观，后者在跨系统对接时更安全，看团队习惯，但无论如何不能碰浮点。

3.2 订单表设计：为什么要把商品快照存下来

订单表设计里有一个必须做对的点：订单明细要把下单那一刻的商品信息完整快照下来，包括商品名、规格、单价、图片。原因很实在——商品是会变的。运营今天把价格从 99 改成 129，明天把标题改了，后天把商品下架甚至删除。但用户三个月前那笔订单，必须永远显示他当时买的东西和价格。

如果不做快照，只存一个商品 ID，等商品被删了，订单详情页就成了一片空白，客服查单查不出东西，财务对账对不上，这是要出事故的。所以订单明细表里的商品名、规格、单价这些字段，是冗余但必须的。做数据库设计时，判断一个冗余字段该不该加，标准就是“这个值在未来是否需要保持历史原样”，如果是，就必须冗余。

订单主表的核心字段包括：订单号、用户标识、订单总金额、实付金额、优惠金额、运费、订单状态、支付方式、支付时间、发货时间、收货信息、备注、创建时间。订单号我强烈建议不要用自增主键直接暴露，用“日期 + 业务标识 + 序列”的方式生成，既避免暴露业务量，也便于按日期分表或排查。

收货信息也要考虑清楚。用户地址是会改的，所以订单里必须存一份下单时的收货人、电话、详细地址的快照，而不是只存地址 ID。这一点和商品快照是同一个逻辑。

3.3 库存表与扣减策略

库存是电商后台最敏感的数据，设计不好直接导致超卖，超卖就是真金白银的损失和用户投诉。库存设计上，我建议至少分三个字段：可售库存、锁定库存、实际库存。可售库存是可以卖的数量，锁定库存是已下单未支付占用的数量，实际库存是仓库里的真实数量，三者关系是实际库存等于可售加锁定。

扣减时机的选择有三种主流方案，各有取舍。

我一般选第三种：下单时把可售库存转入锁定库存，同时记录一条库存流水；支付成功后锁定库存真正扣减，支付超时或主动取消则把锁定库存还回可售。这个方案的关键是要有可靠的超时释放机制，通常是定时任务扫超时订单，或者用延迟消息。定时任务简单可靠，扫描间隔设成一分钟，对十万级订单量完全够用。

防止并发超卖，最直接的办法是在数据库层面用条件更新，把判断和扣减合成一条语句，让数据库的行锁来保证原子性，而不是先查再改。先查后改在并发下必然出问题，两个请求同时查到库存为 1，都判断可以卖，然后都减一，库存变成负一。这是最经典的并发事故，我用一句话总结：任何“读取—判断—写入”的流程，只要涉及共享资源，都要怀疑它有并发问题。

3.4 权限模型：RBAC三张表起步

后台权限分三个层次，很多人只做了第一层就以为完事了。

第一层是登录认证，解决“你是谁”。第二层是功能权限，解决“你能操作哪些菜单和按钮”。第三层是数据权限，解决“你能看到哪些数据”。三层缺一不可，尤其是第三层，最容易被漏掉，也最容易出安全事故。

功能权限用经典的 RBAC 模型就能覆盖，核心是五张表：用户表、角色表、菜单权限表、用户角色关联表、角色菜单关联表。用户通过角色拿到权限，权限点细分到菜单和按钮级别，比如“商品管理”是菜单权限，“商品删除”是按钮权限，后端接口上标注对应的权限码做校验。

数据权限要复杂一些，常见做法是在业务表上冗余归属字段，比如创建人、所属门店、所属部门，查询时根据当前用户的数据范围自动拼接过滤条件。这个拼接一定要在服务端做，绝不能信前端传的过滤参数。我见过有系统把“门店 ID”当普通查询参数传，只要改一下请求参数就能查到别的门店的数据，这是典型的安全漏洞。

菜单表设计上，建议同时存路由路径、组件路径、权限标识、图标、排序、父级 ID、菜单类型。菜单类型区分目录、菜单、按钮三种，前端根据类型决定渲染成可展开的分组、可点击的页面，还是一个隐藏的权限点。这种设计在 Vue 这类框架里配合动态路由非常好用，登录后拉一次菜单树，前端直接生成路由表。

4. 核心功能实现：从登录到跑通一单

4.1 项目骨架与依赖

动手之前先把骨架搭好。后端工程按分层建包，配置文件分环境隔离，日志配置好按天滚动，这些基础工作半天就能完成，但决定了后面几个月顺不顺手。依赖上，核心是 Web 框架、数据库驱动、ORM、连接池、缓存客户端、参数校验、JWT 工具、Excel 导出工具，其余的按需再加。

有一个细节值得提：连接池参数不要用默认值。默认配置通常偏保守，稍微有点并发就排队。我的经验是初始连接数设成 CPU 核数的两倍左右，最大连接数根据数据库承受能力定，再配一个连接有效性检测，避免拿到失效连接。这些参数不是越大越好，连接数超过数据库处理能力反而会拖慢整体。

配置文件要按环境分离，开发、测试、生产的数据库地址和密钥绝不能混在一起。尤其是生产环境的数据库密码，不能明文提交到代码仓库，用环境变量或配置中心注入。这类事情出一次就是大事故，防患于未然的成本极低。

4.2 关键表结构SQL

下面给出几个核心表的建表语句，字段和索引都是我在实际项目里验证过的版本，可以直接拿来改。

CREATE TABLE pms_spu ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键', title VARCHAR(120) NOT NULL COMMENT '商品标题', category_id BIGINT NOT NULL COMMENT '类目ID', brand_id BIGINT DEFAULT NULL COMMENT '品牌ID', main_image VARCHAR(255) DEFAULT NULL COMMENT '主图地址', detail TEXT COMMENT '商品详情', price_low DECIMAL(12,2) NOT NULL DEFAULT 0 COMMENT '最低价，冗余便于列表展示', price_high DECIMAL(12,2) NOT NULL DEFAULT 0 COMMENT '最高价', sale_count INT NOT NULL DEFAULT 0 COMMENT '销量', publish_status TINYINT NOT NULL DEFAULT 0 COMMENT '0下架 1上架', deleted TINYINT NOT NULL DEFAULT 0 COMMENT '逻辑删除', create_by BIGINT DEFAULT NULL COMMENT '创建人', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id), KEY idx_status_time (publish_status, create_time) ) COMMENT='商品SPU表'; CREATE TABLE pms_sku ( id BIGINT NOT NULL AUTO_INCREMENT, spu_id BIGINT NOT NULL COMMENT '所属SPU', sku_code VARCHAR(64) NOT NULL COMMENT 'SKU编码，唯一', spec_desc VARCHAR(255) NOT NULL COMMENT '规格描述，如 红色/M', image VARCHAR(255) DEFAULT NULL, price DECIMAL(12,2) NOT NULL COMMENT '售价', stock INT NOT NULL DEFAULT 0 COMMENT '可售库存', locked_stock INT NOT NULL DEFAULT 0 COMMENT '锁定库存', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', PRIMARY KEY (id), UNIQUE KEY uk_sku_code (sku_code), KEY idx_spu (spu_id) ) COMMENT='商品SKU表'; CREATE TABLE oms_order ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '业务订单号', user_id BIGINT NOT NULL COMMENT '下单用户', total_amount DECIMAL(12,2) NOT NULL COMMENT '商品总额', pay_amount DECIMAL(12,2) NOT NULL COMMENT '实付金额', freight DECIMAL(12,2) NOT NULL DEFAULT 0 COMMENT '运费', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1待发货 2已发货 3已完成 4已取消 5退款中 6已退款', receiver_name VARCHAR(50) NOT NULL COMMENT '收货人快照', receiver_phone VARCHAR(20) NOT NULL COMMENT '联系电话快照', receiver_addr VARCHAR(255) NOT NULL COMMENT '地址快照', pay_time DATETIME DEFAULT NULL, deliver_time DATETIME DEFAULT NULL, remark VARCHAR(255) DEFAULT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_status (user_id, status), KEY idx_status_time (status, create_time) ) COMMENT='订单主表'; CREATE TABLE oms_order_item ( id BIGINT NOT NULL AUTO_INCREMENT, order_id BIGINT NOT NULL, order_no VARCHAR(32) NOT NULL, spu_id BIGINT NOT NULL, sku_id BIGINT NOT NULL, sku_code VARCHAR(64) NOT NULL, product_name VARCHAR(120) NOT NULL COMMENT '下单时商品名快照', spec_desc VARCHAR(255) NOT NULL COMMENT '下单时规格快照', image VARCHAR(255) DEFAULT NULL, price DECIMAL(12,2) NOT NULL COMMENT '下单时单价快照', quantity INT NOT NULL, PRIMARY KEY (id), KEY idx_order (order_id), KEY idx_sku (sku_id) ) COMMENT='订单明细表';

这几个表里有几个设计点值得单独说明。SPU 表冗余了最低价和最高价，是为了列表页展示价格区间时不用每次都去聚合 SKU 表，代价是改价时要同步更新，用服务层保证一致。订单明细表存了商品名和规格快照，前面说过原因。订单表的索引设计遵循“等值字段在前、范围字段在后”的原则，用户加状态、状态加时间这两个组合索引，覆盖了后台最常见的两种查询场景。

4.3 登录鉴权与接口拦截

登录流程不复杂，但细节决定安全。用户提交账号密码，后端校验后生成令牌返回，前端后续请求把它放在请求头里。密码存储必须加盐哈希，绝不存明文，也绝不存简单的 MD5——那玩意早就能被彩虹表撞穿了。

拦截器负责在每次请求进来时解析令牌，校验有效性，把用户信息放进上下文，然后检查该接口所需的权限码是否在当前用户的权限集合里。这里有个容易出错的地方：权限校验不能只看有没有登录，必须看有没有对应权限。我见过不少系统把所有接口都配了“登录即可访问”，结果客服账号能调商品删除接口，只是前端没给他显示那个按钮而已。任何前端隐藏都不能当作安全措施，服务端必须自己校验。

数据权限的拦截更微妙一些。我的做法是在服务层提供一个统一的查询条件构造方法，根据当前用户的数据范围自动追加过滤条件，任何涉及敏感数据的查询都必须走这个方法。同时写一个代码检查约定：所有绕过这个方法的查询都要在评审时说明理由。靠人自觉不可靠，靠机制才稳妥。

令牌过期和续期也要想清楚。令牌有效期设太短，运营人员一天要重新登录十几次，会骂人；设太长，一旦泄露风险就大。折中方案是访问令牌短一些，配一个刷新令牌，前端在访问令牌失效时自动用刷新令牌换新的，用户无感知。这套机制实现起来不复杂，体验提升明显。

4.4 商品发布与订单流转的实操记录

我按真实操作顺序把一条链路走一遍，这样你能看到各模块怎么串起来。

商品发布环节：运营进入商品列表，点新增，先选类目，系统根据类目动态加载对应的属性模板，填标题、上传主图、编辑详情。然后进入规格设置，选择要用的规格项（比如颜色、尺码），系统自动生成所有组合，运营逐个填价格和库存。提交后，后端先做业务校验——标题非空、至少一个 SKU、价格大于零、库存非负——然后在一个事务里写 SPU 表、写 SKU 表、写库存表、写操作日志，全部成功才提交。任何一步失败整体回滚，避免出现有 SPU 没 SKU 的脏数据。

订单流转环节：用户下单后，订单状态是待支付，同时库存从可售转入锁定。支付成功后，状态变为待发货，锁定库存真正扣减，写支付流水。仓储登录后台看到待发货列表，打印面单、填物流单号、点发货，状态变已发货。用户确认收货或系统超时自动确认，状态变已完成。

状态流转这块，必须用状态机做白名单校验，绝不能随便写个更新语句让状态想改成什么就改成什么。我的做法是定义一个允许的流转映射，每次变更前先校验当前状态能不能流转到目标状态，不合法直接抛业务异常。这样能挡住大量脏操作，比如把已完成订单改回待支付，或者跳过发货直接完成。

发货这一步还要注意重复提交。仓储同事网络卡顿，连点两次发货按钮，如果接口没有幂等控制，就会发两次货、写两条物流记录。解决办法很简单，发货前先校验订单状态必须是待发货，更新时带上状态条件，影响行数为零就说明已经被处理过了。这个思路在所有状态变更场景都适用，成本极低但效果显著。

5. 常见问题与排查实录

5.1 问题速查表

后台系统跑起来之后，遇到的问题类型其实很集中。我把这几年遇到的高频问题整理成一张表，附上排查思路和处理办法，遇到类似现象可以直接对照。

这张表里最值得展开的是库存负数那个问题。现象是偶尔出现负库存，日志里看不出异常，因为两个请求各自都执行成功了。根因是把判断和扣减拆成了两步，中间存在时间窗口。修复方案就是把两步合成一步，让数据库的行锁来保证原子性。改完之后这类问题再没出现过。这也让我形成了一个习惯：凡是涉及共享资源的判断加修改，先想能不能用一条语句解决。

5.2 越权、导出、日志这三类专属坑

后台系统有三类问题特别典型，几乎每个项目都会遇到，我单独说说。

第一类是越权访问。最常见的形式是接口只校验了登录，没校验数据归属。比如订单详情接口传一个订单 ID 就能查，客服 A 改一下 ID 就能看到客服 B 负责的订单，甚至能看到别的商户的订单。这类问题的排查方式是做一轮接口清单梳理，逐个问“这个接口的数据范围应该是什么”，然后补上归属校验。我的经验是，权限设计阶段就把数据范围作为必填项写进接口文档，后面开发照着做，比事后补要省事得多。

第二类是导出功能拖垮服务。运营很喜欢导出，动辄几万条。如果把数据一次性查进内存再写文件，很容易触发内存溢出，尤其是在容器内存限制比较紧的环境里。正确做法是流式查询，一边读一边写，配合分批处理，每批几千条写完就释放。同时给导出加个上限和异步机制，超过一定条数转为后台任务，生成完再通知下载。这个改造投入不大，但能避免很多半夜被告警叫醒的情况。

第三类是操作日志缺失。后台系统出问题，第一句话永远是“谁改的”。如果没有操作日志，只能靠猜。我的做法是在关键写操作上统一记录日志，包括操作人、操作时间、操作类型、业务标识、变更前后的关键字段值、请求来源。实现上可以用切面统一拦截，也可以在每个服务方法里显式调用。切面省事但拿不到业务语义，显式调用啰嗦但信息全，我倾向于关键业务显式记录，通用操作走切面。

还有一个容易被忽略的点是日志本身不能成为负担。我见过有系统把整个请求体和响应体都塞进日志表，一天几百万条，数据库直接被日志撑爆。正确做法是只记关键字段的变更，敏感信息脱敏，日志表定期归档。日志是用来排查问题的，不是用来存全量数据的。

6. 我在实际项目里的一些体会

做完几套后台系统之后，我最大的感受是：决定一个后台系统好不好用的，往往不是技术有多先进，而是那些最不起眼的细节有没有做到位。列表页的筛选条件是否符合运营的思考习惯，批量操作的确认提示是否足够清晰，错误提示能不能让人一眼看懂哪里填错了，导出按钮点下去有没有反馈——这些看起来琐碎的东西，才是使用者每天真正在打交道的地方。

技术上我会坚持几条底线。金额不用浮点，库存扣减不拆成两步，状态变更必须走白名单校验，权限校验必须在服务端做，关键操作必须留痕。这几条每一条背后都有真实事故支撑，不是纸上谈兵。至于架构选微服务还是单体、前端用哪个框架、缓存要不要上，这些反而是可以商量的，因为它们影响的是开发效率，而那几条底线影响的是数据正确性和安全性。

最后分享一个我最近在用的做法：每加一个新功能，先问自己一句“如果这个功能被误操作了，最坏的结果是什么”。如果答案是数据丢失或者资损，那就必须加二次确认、加权限控制、加操作日志、加可回滚机制。如果答案只是“页面显示不对”，那就不必过度设计。用这个标准去衡量，能省下大量不必要的复杂度，也能保证真正重要的地方一个都不漏。这套思路用久了，你会发现后台系统的设计其实没那么玄乎，无非是把每个环节的最坏情况想清楚，然后老老实实堵上。