超市订单管理系统分析：JSP+Servlet+JDBC后台架构与排障

接手一个超市订单管理系统的项目分析我习惯先不看代码先问一句这套东西到底卡在谁手里、卡在哪个环节。标题里的“smbms”和“超市订单管理系统”摆在一起指向的其实是一类非常典型的业务系统——围绕供应商、商品账单、订单流水、操作用户四条线转的中小型进销存后台。它解决的问题很具体一家门店或一个小型商贸公司每天有几十上百条采购与销售流水靠 Excel 记会串行、会对不上账靠大型 ERP 又太重、太贵、没人会用中间这块空白就需要一个轻量的超市订单管理系统来填。这篇文章适合三类人看正在做同类后台练手的开发者能从里面看到表怎么设计、分页怎么算、权限怎么收已经有一版能跑的系统但总觉得别扭的人能看到分层与排查的具体改法还有准备接手别人留下的老系统、需要快速摸清全貌的维护者。我会把项目分析拆成选型、数据、结构、模块、排查、改造几步来讲每一步都给出为什么这么做而不只是怎么做。1. 项目整体定位与技术选型拆解1.1 先搞清楚这套系统真正的服务对象和业务边界很多人一上来就写代码写到一半发现需求自己都想不明白最后做出来的东西功能挺多但没人用。我一般在动手前会先把系统的服务对象按“角色”切开超市订单管理系统这个场景下实际只有三类人在用一是门店的业务操作员负责录入账单、登记供应商信息二是门店的管理者负责看订单汇总、决定哪些账单已经结算三是系统的超级管理员管账号、管角色、管别人能不能删数据。这三类人的诉求完全不同操作员要的是“录得快、少填字段”管理者要的是“一眼看清欠款和已付”管理员要的是“权限别乱”。把这些角色对应的动作列出来业务边界就清楚了。系统要管的是供应商档案、账单流水、订单与账单的对应关系、用户与角色不需要管的是商品库存的实时扣减、会员积分、线上支付对接——这些属于电商或者 POS 系统的地盘塞进来只会让一个轻量后台迅速失控。我在分析类似项目时经常见到有人往里加购物车、加库存预警最后数据库表翻了三倍核心的账目对平功能反而做得很糙。所以第一层的取舍就是明确这是一个内部管理后台不是面向顾客的前台它的每一个界面都应该是表格、表单、查询条件而不是花哨的展示页。确定了这一点后面的所有设计都有了准绳。表单字段该不该加看操作员一天要录多少条列表要不要分页看数据量能不能一屏放下要不要做角色权限看有没有“不同人该看到不同数据”的需求。这套判断逻辑比任何技术选型都重要因为它决定了你做出来的东西是能用还是能用但没人想用。1.2 为什么这个体量适合用 JSP Servlet JDBC 的原生组合说到技术选型我得先泼一盆冷水这套系统用 Spring Boot 三分钟就能搭起来为什么还要用 JSP Servlet JDBC 这种看起来“老掉牙”的组合答案不是技术先进性问题而是可观测性和学习性价比的问题。Spring 帮你做了太多事一个请求进来从过滤器链到拦截器到 AOP 到事务代理中间隔了七八层出了问题你只能靠日志猜。而这个体量的系统总共就那么几个页面请求路径短、生命周期清晰用原生 Servlet 你能完整地看到“请求进来—参数解析—业务处理—跳转响应”的全过程每一行都是你自己写的出问题定位起来极快。具体到实现层面JSP 承担视图渲染Servlet 承担控制器职责JDBC 直连数据库做数据访问中间用一个 DAO 层隔离 SQL。这套组合的最大好处是没有魔法页面上一个下拉框的值从哪来你能顺着 Servlet 一路找到那条 SQL数据库里少了一条记录你能顺着日志找到是哪次提交出了问题。对于一个用来理清后台系统脉络的项目来说这种透明性比工程化程度更值钱。当然代价也很明确。JDBC 直连意味着每次操作都要自己开连接、关连接不引入连接池的话并发一高就顶不住JSP 里嵌 Java 代码写多了会变成一锅粥后期维护很难受没有依赖注入对象之间的组装全靠手工 new。所以我的做法是保留原生组合的清晰骨架但在三个地方做补强——引入连接池解决连接复用用过滤器统一处理编码和登录校验用 JSTL 标签替代页面里的 Java 脚本片段。这三处补强不改动整体结构但能把最扎手的问题提前摁住。1.3 技术栈清单与版本取舍的几个实际考量把清单摊开来看这套系统依赖的东西并不多但每一项都有坑。层次技术选型选择理由需要注意的点视图层JSP JSTL EL无需前端构建服务端直出调试直观页面里别写 Java 脚本全用标签和 EL控制层Servlet 3.0注解配置免去 web.xml 大量配置路径清晰注解路径别重复映射冲突排查很费时数据层原生 JDBC 手写 DAOSQL 完全可控便于理解执行计划必须做资源关闭否则连接池会被耗干数据库MySQL 5.7 / 8.0免费、生态好、语法通用8.0 驱动类名与时区参数和 5.7 不同连接池Druid 或 HikariCP连接复用避免频繁握手开销池大小别拍脑袋定要按并发估构建Maven依赖管理、打包一体化打包后静态资源路径容易踩坑版本取舍上有两个具体决定值得说。第一是JDK 版本不要盲目追新Servlet 容器对高版本 JDK 的兼容性有时候会给你惊喜选团队里最稳的那个版本能省掉一半莫名其妙的启动报错。第二是数据库驱动必须和数据库服务端版本对齐5.x 的驱动连 8.0 的服务端常见的表现是时区报错或者认证插件不匹配报错信息还特别不直观很多人会误以为是密码错了折腾半天。还有一个容易忽略的是字符集。数据库建库时如果用的是默认字符集中文供应商名称、商品描述在写入时可能变成问号而且是那种“有时候正常有时候乱码”的间歇性问题。我的习惯是建库建表时显式指定 utf8mb4连接串里也带上字符集参数宁可多写一行配置也不要留一个随机出现的坑。2. 数据库设计整个系统真正的地基2.1 五张核心表的关系与设计意图后台系统做得好不好八成看表设计。这套超市订单管理系统的数据模型其实很朴素围绕五张表转用户表、角色表、供应商表、账单表、地址表。关系是这样串起来的。用户表里有一个角色字段指向角色表的主键一个用户对应一个角色一个角色下可以有多个用户这是典型的一对多。供应商表独立存在记录供货方的编码、名称、联系人、电话、地址、传真这些档案信息。账单表是业务核心每一条账单记录一笔采购或销售流水包含账单编码、商品名称、商品描述、计量单位、数量、总金额、是否已付款以及一个指向供应商的外键——也就是说每一笔账单都必须挂在某个供应商名下这个外键是订单与供应商联动的关键。地址表则挂在用户下面记录收货地址、邮编、联系电话一个用户可以有多条地址。这里有个设计上的取舍值得说清楚账单表里的“是否已付款”用的是一个很小的整型标记而不是独立的付款流水表。这个设计的优点是查起来极快一个条件筛选就能拉出所有未结算的账单缺点是无法记录部分付款、多次付款的场景。对于一个小型门店来说采购基本是“一次结清”或者“月结一次”前者完全够用如果业务真的复杂到要记录每次付款的时间和金额那就得拆出付款明细表账单表只留汇总字段。我在分析这个模型时会明确标注这是面向简单结算场景的简化设计而不是把它当成通用方案推荐给别人。还有一个细节几乎所有业务表都有创建人、创建时间、修改人、修改时间这四个字段。这不是冗余是审计留痕的基础。当账单金额被人改过、供应商电话被人动过能查出是谁在什么时候改的这在内部管理系统里是刚需比任何花哨的功能都重要。很多练手项目会省掉这四个字段等到出问题想追责时才发现无从查起那时候补字段的成本远高于一开始就设计进去。2.2 字段设计里的几个关键取舍与避坑字段设计上有几个地方我踩过坑值得展开说。主键用自增整型还是业务编码这套系统里用户有用户编码、供应商有供应商编码、账单有账单编码看起来都可以做主键。但我建议主键一律用自增整型业务编码单独做唯一索引。原因很实在业务编码是人编的可能重复、可能改、可能有特殊字符一旦拿它当主键做外键关联改一次编码就要级联更新一堆表。自增主键没有业务含义改什么都不影响关联关系唯一索引负责拦重复就行。金额字段用什么类型这是最经典的坑。用浮点数存金额做几次累加就会冒出 0.000000001 的误差对账的时候能让人崩溃。正确做法是用定点小数类型明确指定小数位数比如两位。如果预算紧张或者数据量极大也可以用整型存“分”展示时再除。我在评审别人的表结构时看到金额字段是浮点型基本可以直接判定这个系统迟早要出对账纠纷。字符串长度给多少很多人习惯性地全给很长的长度觉得“反正不占地方”。实际上数据库会按定义分配存储过长的字段在某些场景下会拖慢索引、影响内存中的排序效率。我的做法是按实际业务估供应商名称给到足够容纳常见公司全称的长度商品描述给中等长度电话、邮编这种给固定合理长度。估不准的时候宁可稍宽一点但别一上来就给到极端值。要不要加逻辑删除标记账单和供应商这类数据物理删除是有风险的——删了之后历史统计对不上审计也查不到。加一个删除标记字段做逻辑删除查询时统一带条件过滤代价是每条 SQL 都要多写一个条件收益是数据永远可追溯。这笔账我觉得很划算尤其是账单数据删错了就是钱的问题。2.3 建表与初始化数据的实操落地建库建表的顺序有讲究必须先建被引用的表再建有外键的表。顺序是角色表、用户表、供应商表、地址表、账单表。如果反过来建表会因为外键指向不存在的表而失败。建库时的两个关键参数要显式指定字符集用 utf8mb4排序规则配套设置。建表时引擎统一用 InnoDB因为它支持事务和行级锁账单这类涉及金额的操作必须要有事务保障。初始化数据的准备是最容易被忽视的一步。我的习惯是准备三份脚本一份是建表脚本一份是基础数据脚本一份是批量测试数据脚本。基础数据里至少要有两个角色、三个不同角色的用户、五个供应商、二十条左右分布在不同付款状态的账单。测试数据的价值在于它能让你在做分页和查询筛选时立刻看到效果——总共二十条每页五条翻到第四页正好边界翻到第五页应该是空这种边界情况只有真实数据才能验证出来。提示初始化脚本里的用户密码不要存明文。哪怕是练手项目也养成存摘要值的习惯脚本里直接写加密后的字符串。这个习惯一旦养成后面接手真实项目时就不会犯低级错误。批量测试数据我一般用一段脚本循环生成金额、日期、供应商都随机分布这样在测试“按日期范围查询”“按金额排序”“按供应商筛选”这些功能时能立刻发现 SQL 里的条件写漏了或者排序字段搞错了。看起来是小事但正是这些小事决定了这个系统你敢不敢真拿去用。3. 分层架构与核心代码结构3.1 四层结构各自的职责边界这套系统的代码结构是标准的四层实体层、数据访问层、业务层、控制层外加视图层。分层这个词人人会说但真正落地时最常见的毛病是职责越界——SQL 写在了 Servlet 里业务判断写在了 JSP 里最后整个项目变成一锅粥。我给的边界是这样划的。实体层只做一件事把数据库的一行映射成一个对象字段和表字段一一对应不写任何业务逻辑也不写任何数据库操作。数据访问层只做一件事拿着参数去查或改数据库返回实体或者集合不判断“这个用户能不能删”那是业务层的事。业务层负责组合多个数据访问操作、做业务规则校验、开启和提交事务比如“删除供应商之前先检查有没有未结算的账单关联它”。控制层负责收参数、调业务、选视图、跳页面不做任何业务判断也不写 SQL。这套边界守住了好处是显而易见的改一个查询只需要动数据访问层加一条业务规则只需要动业务层换一个页面只需要动视图层互不牵连。我见过太多项目把 SQL 直接写在控制层里后来要加一个缓存发现得改二十个地方改到最后干脆不做了。具体到类的组织上用户、供应商、账单、地址这四块业务每块对应一个实体类、一个数据访问接口加一个实现类、一个业务实现类控制层则按功能拆成若干个 Servlet。名字上保持一致的前缀比如都以 User、Provider、Bill 开头找代码的时候一眼就能定位。这种看似笨拙的命名一致性实际上比什么设计模式都管用因为它降低了别人接手时的心智负担。3.2 实体类与通用数据访问代码的复用写法实体类写起来枯燥但必须规范。字段名和表字段名对应类型选对——日期用日期类型、金额用定点小数对应的类型、整型标记用小整型别一律用字符串图省事。每个字段配标准的读写方法再补一个能打印全部字段的字符串表示方法调试的时候能省很多事查出来的对象直接打印一眼就能看出哪个字段是空。数据访问层最容易写重复代码。四张表都要做“按条件查总数”和“按条件分页查列表”这四个方法里除了表名和条件不同其余几乎一样。我的做法是抽一个通用的查询工具把连接获取、参数绑定、结果集映射、资源关闭这几件事封装起来各表的数据访问实现只传 SQL 和参数。这样每个具体实现里的代码量能砍掉一大半而且资源关闭的问题一次性解决不会出现某张表忘了关连接的情况。这里有个细节必须强调结果集到实体的映射要显式写别依赖自动映射。自动映射看起来省事但字段名和属性名稍有差异就映射不上而且是静默失败——不报错只是值是空的。等你发现列表里某一列全是空白回头找原因能耗掉半天。显式映射麻烦一点但每一行都是确定的。再就是日期和金额的处理。数据库里是日期类型实体里也要用日期类型千万不要在中间环节转成字符串再转回来格式一多就乱。金额同理数据库定点小数Java 侧用对应的高精度类型从查询到计算到展示全程保持精度不要中途为了省事转成浮点。3.3 字符编码过滤器与登录拦截的落地方式过滤器是这套结构里性价比最高的东西两个过滤器就能解决大问题。第一个是字符编码过滤器。做法很简单在过滤器里统一设置请求和响应的字符编码并且对请求编码要放在读取任何参数之前——这一点非常关键因为一旦参数被读取过再设置编码就不生效了表现就是“有时候中文正常有时候变问号”非常难查。把这段逻辑放在过滤器最前面整个应用的所有请求就统一了不用每个 Servlet 里重复写。第二个是登录校验过滤器。逻辑是拦截所有需要登录才能访问的路径从会话里取当前登录用户取不到就跳转到登录页登录页和静态资源要放行否则会陷入无限重定向。这里有个坑放行名单必须包含登录页的路径、登录提交的路径、以及样式脚本图片这些静态资源路径漏一个就会出现“登录页样式全丢”或者“登录页自己跳自己”的诡异现象。注意过滤器的拦截路径配置要写清楚用通配符匹配整个应用时一定要把放行名单核对三遍。我见过有项目因为漏放行静态资源登录页打开是一片白板排查了两小时才发现是过滤器把样式文件拦了。另外一个小技巧会话超时时间要显式设置别用默认值。默认值有时候长到让人以为登录状态永远不过期测试权限功能时根本测不出效果。设一个合理的时长然后在用户长时间不操作后重新登录这套流程本身也是对会话管理的一次真实验证。4. 核心模块实现要点与实操过程4.1 登录与会话管理看似最简单坑最多登录功能看起来是最简单的实际上它是整个系统的安全问题集中地。流程是这样用户提交账号密码控制层接收后调业务层业务层先按账号查出用户记录再把提交的密码做同样的摘要运算与库里存的摘要值比对一致就通过不一致就返回错误。这里有两个关键点。第一查询必须按账号精确匹配且用参数化方式传值绝不能拼接字符串否则就是注入漏洞的入口。第二密码比对必须比对摘要值不能比对明文库里也不该存明文。摘要算法上教学项目里常见的是早期的消息摘要算法但我要明确说一句这类算法现在只能防住“数据库泄露后密码直接被看到”防不住彩虹表。稍微认真一点的做法是加盐——每个用户一个随机盐值和密码一起做摘要盐值单独存一列。再好一点是用专门为密码设计的慢哈希算法计算一次要几十毫秒暴力破解的成本立刻上去了。对一个内部管理系统来说加盐已经能把风险降到可接受的水平。会话管理上登录成功后把用户对象放进会话同时把角色标识也放进去后面做权限判断时直接用。会话里只放必要信息不要把整个用户对象连同密码摘要一起塞进去那等于把敏感信息挂在服务端内存里一旦有会话序列化或者日志打印就泄露了。还有一个细节登录失败要有次数限制或者至少要有日志记录。没有限制的登录接口等于给暴力破解开了绿色通道。简单做法是记录同一账号的连续失败次数超过阈值就锁定一段时间。这个功能代码量很小但体现了对安全的基本认知。4.2 用户管理分页查询是绕不开的核心难点分页是这类后台系统里技术含量最集中、也最容易写错的地方。原理其实不复杂前端传当前页码和每页条数后端算出偏移量用限定范围的查询取出一页数据同时查一次总数用于计算总页数。偏移量的计算是关键偏移量等于当前页码减一乘以每页条数。这里必须做参数校验因为用户可以在地址栏里随便改页码。页码小于一的时候要纠正为一页码大于总页数的时候要纠正为总页数否则查出来就是空列表用户还以为数据丢了。每页条数也要限制上限不然有人传个一万一次查询把整张表拉出来数据库连接直接被占满。总页数的计算有个经典坑总数除以每页条数如果除不尽要向上取整。直接整除会导致最后一页的数据永远查不出来。我见过有项目用整除数据明明有二十一条、每页十条但只能翻两页第二十一条永远看不到排查了半天才发现在取整上。参数含义计算方式常见错误当前页码第几页前端传入需做上下界纠正未校验传入零或负数导致偏移量为负每页条数一页多少条前端传入需设上限上限过大一次拉全表偏移量从第几条开始取页码 - 1× 每页条数忘了减一第一页就漏了前几条总记录数满足条件的总条数单独一次统计查询条件与列表查询不一致总数对不上总页数一共几页总记录数 ÷ 每页条数向上取整直接整除最后一页数据丢失除了分页用户管理还有两个要点。一是条件组合查询按用户名模糊查、按角色精确查两个条件可以组合。这里的坑在于模糊查询的参数拼接和条件拼接必须用参数化方式同时动态拼接条件时要注意空格和连接词漏一个空格就变成语法错误。二是删除前的关联检查删除一个用户之前要考虑他创建过的账单怎么处理是禁止删除还是保留孤儿数据这个规则必须在业务层明确下来而不是让数据库外键报错来兜底——外键报错的信息对用户来说毫无意义。4.3 供应商与账单模块联表查询与金额校验的实操供应商模块相对简单本质是增删改查加分页但它的价值在于档案数据的完整性。供应商编码要唯一名称不能为空联系电话格式要校验。这些校验如果只放在前端随便绕一下就失效了所以服务端必须再校验一遍。我的原则是前端校验为了体验服务端校验为了正确两边都要有。账单模块是真正的重头戏因为它涉及跨表联动。列表查询时账单表要显示供应商名称而账单表里存的是供应商标识所以必须做联表查询把供应商名称带出来。这个查询的写法有两种一种是用连接查询一次取出另一种是先查账单再用标识去查供应商后者会产生典型的查询次数放大问题——一页十条账单就是十一次查询性能很差。正确做法是连接查询一次搞定。账单的金额也有校验逻辑总金额应该等于单价乘以数量如果是用户手填总额就要在服务端做一致性校验对不上要提示。这里的比较不能用浮点直接比要用定点小数的比较方式否则会因为精度问题误判。新增账单时还有一层业务约束账单必须关联一个已存在的供应商。所以提交时先校验供应商标识是否有效再插入。删除供应商时反过来先检查有没有未结算的账单挂在他名下有就不许删。这个双向约束是保证数据不出现孤儿记录的关键很多项目只做了一边结果删了供应商之后账单列表里出现大片空白供应商名称看着就很不专业。修改操作要注意并发覆盖的问题。两个人同时打开同一条账单编辑A 先保存B 后保存B 会覆盖 A 的修改。简单做法是加一个版本号或者用修改时间做乐观锁校验更新时带上原来的修改时间如果库里的修改时间和带的不一致说明期间被人改过提示用户刷新重试。这个改动只在更新语句里多一个条件成本很低但避免了“我的修改莫名其妙没了”这类投诉。4.4 账单状态与结算逻辑的落地细节账单的付款状态这个字段看着简单实际操作里最容易出问题的是状态流转的合法性。比如从“未付款”改成“已付款”是允许的从“已付款”改回“未付款”就要谨慎因为涉及金额统计的重算。我的做法是在业务层把允许的流转关系列出来不符合的直接拒绝而不是让前端随便传什么状态就写什么状态。结算相关的统计查询也值得单独说。管理者最关心的是“这个月一共采购了多少、还有多少没付”这类统计不能靠前端把列表拉下来自己加数据量一大就卡死。正确做法是写聚合查询在数据库侧算出汇总返回一个结果对象。这里要注意统计条件的口径必须和列表查询一致否则会出现“列表显示十二条未付款统计说十条”的对不上账用户第一反应就是不信任这个系统。还有一个小细节是账单编码的生成。如果是用户手填就要做唯一性校验如果是系统生成就要考虑并发情况下不重复——简单做法是时间戳加随机后缀或者用一个独立的序列表。我倾向于系统生成加唯一索引兜底人编的编码在多人操作时几乎一定会撞。5. 常见问题与排查技巧实录5.1 乱码、空指针、白页三大高频问题的定位路径这三类问题占了这类项目排障量的绝大多数值得逐个说清楚定位思路。乱码的表现是中文变问号或者变成一堆奇怪符号。排查顺序是先看数据库里的数据本身对不对如果库里就是乱的问题在写入链路检查连接串字符集、建表字符集、过滤器编码设置如果库里是对的但页面显示乱问题在输出链路检查响应内容类型和页面编码声明。这个“先分清是写坏了还是读坏了”的思路能省掉大量时间因为很多人的第一反应是去改页面编码改了半天发现根源在写入。空指针的定位靠的是看堆栈的最上面一行。堆栈会告诉你哪个类的哪一行抛的直接跳过去看那一行的对象有没有可能是空。最常见的三种情况查询结果为空却没判空就取属性、会话里取用户没判空就取用户标识、请求参数没传到导致解析出来是空。第三种最隐蔽因为参数名写错一个字母值就是空而且不报错一路传到业务层才炸。白页是指页面什么都不显示也不报错或者返回状态码是成功但内容是空的。常见原因视图路径写错转发到了一个不存在的页面过滤器或拦截器把请求拦了但没有正确放行返回了一个空响应页面里抛了异常但被吞掉了。定位方法是先看服务端日志有没有异常没有的话在转发前后打日志确认走到了哪一步。5.2 分页与总数对不上、查询结果为空的排查实录分页相关的问题我总结了一套固定的检查顺序基本能覆盖九成情况。第一步看总数查询和列表查询的条件是不是同一套。我见过很多次是因为列表查询加了状态过滤总数查询忘了加结果总页数按全量算翻到后面几页全是空。第二步看偏移量算得对不对特别是第一页的时候偏移量应该是零如果是负数不同数据库的表现不一样有的报错有的返回全量。第三步看排序。分页查询必须带确定的排序字段否则数据库返回的顺序是不保证的翻页的时候会出现同一条记录在两页里都出现、或者某些记录从来没出现过。这个坑极其隐蔽因为它不报错只是数据看着不对劲。排序字段最好用主键或者创建时间这种唯一性强的字段别用状态这种大量重复的字段。查询结果为空的排查我的顺序是先在数据库客户端里把拼出来的 SQL 手动跑一遍确认数据本身查得出来然后看参数有没有正确传进来在业务层打个日志把参数打出来最后看结果映射有没有问题字段名和属性名是否对得上。这三步走完问题基本就无所遁形了。5.3 常见问题速查表与独家避坑经验把高频问题整理成表出问题时先对号入座能省下大量试错时间。现象最可能的原因快速验证方式处理方式中文写入后变问号连接串或建表字符集不匹配查数据库里实际存储值统一字符集检查过滤器顺序页面样式全部丢失过滤器拦截了静态资源看静态资源的请求状态码放行名单补上资源路径登录页反复重定向登录页路径被拦截看浏览器地址栏变化放行登录页与提交路径最后一页数据缺失总页数计算未向上取整比较总数与页数乘积改用向上取整翻页出现重复记录分页查询缺少确定排序连续翻页对比记录标识加主键或时间排序删除报外键约束错误存在关联数据未检查查关联表是否有引用业务层前置校验并给友好提示金额累加出现小数误差金额字段用了浮点类型多次相加观察尾数改为定点小数或整型存分修改被莫名覆盖并发更新无版本校验两人同时编辑同一条加乐观锁校验修改时间再分享几条文档里不会写的经验。日志要打在关键节点上不是越多越好而是在“参数进来”“数据库查询前”“查询结果出来”“跳转之前”这几个点上打出问题时能立刻定位到是哪一段断了。异常不要吞捕获了要么处理要么往上抛最忌讳捕获了打印一行就完事堆栈丢了等于什么都没留。还有一条改代码前先复现。很多人看到报错直接改改完发现还是报错因为改的地方根本不是根因。先稳定复现再定位再改改完再复现验证这个闭环比任何调试技巧都管用。6. 从能跑的原型到可维护系统的改造思路6.1 连接池与事务两处改动带来质的提升系统能跑起来和能给人用中间隔着的往往是这两件事。连接池解决的是连接创建开销问题。直连模式下每次数据库操作都要建立一次物理连接这个过程涉及网络握手和身份认证耗时是毫秒级的看着不多但一个页面要查好几次数据库并发一上来连接数就爆了。引入连接池后连接被复用取连接变成从池子里拿一个现成的开销降到微秒级。配置上有三个参数要调初始连接数、最大连接数、最大等待时间。最大连接数不是越大越好超过数据库服务端的连接上限会直接报错等待时间设短一点让拿不到连接的请求快速失败而不是排队排到超时。事务解决的是多步操作的一致性问题。最典型的场景是新增账单后要更新对应供应商的累计金额两步操作必须一起成功或一起失败。不用事务的话第一步成功第二步失败数据就不一致了而且这种不一致很难被发现等到月底对账才暴露出问题。做法是把这两步包在一个事务里任何一步抛异常就整体回滚。要注意的是事务的边界要放在业务层不能在数据访问层随便开否则一个业务操作会变成多个独立事务失去了意义。注意用连接池加事务时一定要保证同一个事务里的多次数据库操作拿到的是同一个连接否则事务根本不生效。这个坑在手工管理连接的项目里非常常见表现是回滚了但数据还是脏的。6.2 安全加固清单几件低成本高收益的事安全这块不用做到极致但几个基本项必须过一遍。参数化查询是第一位的所有涉及用户输入的 SQL 都必须用占位符传参字符串拼接一律禁止。这一条能挡掉绝大部分注入风险而且改造成本极低只是写法的区别。权限校验放在服务端。前端隐藏按钮只是体验优化真正的拦截必须在服务端做。做法是在业务层或者控制层判断当前登录用户的角色没有权限的操作直接拒绝并返回明确提示。特别是删除、修改金额这类敏感操作一定要校验。敏感信息脱敏。列表页展示用户信息时手机号、地址这类可以部分打码日志里绝对不要打印密码、完整手机号这类信息。很多人调试时图方便把整个对象打印出来日志文件一存就是几个月等于把敏感数据长期留在了磁盘上。会话安全。登录后更换会话标识退出时销毁会话会话超时时间设置合理。这几条都是标准动作代码量不大但能避免会话固定攻击这类问题。6.3 我个人在这个项目上的几点实操体会最后说几句掏心窝子的经验。先跑通一条完整的链路再铺开做其他模块。我最开始做这类系统时喜欢把五张表的增删改查全写完再联调结果一联调全是问题因为基础的分页、编码、会话这些公共部分没验证过就被复制到了所有模块错一次等于错五遍。后来改成先把用户模块从头到尾跑通——登录、列表、分页、新增、修改、删除全部验证一遍把公共部分的坑踩完再复制到其他模块效率反而高了一倍。数据库设计阶段多花一天编码阶段少花三天。字段类型、长度、索引、外键这些在纸上定清楚了再动手后面改起来成本极高。特别是索引等数据涨到几万条发现查询慢再去加索引还要评估对写入的影响那时候就是被动应付了。建表时就把高频查询条件的字段加上索引比如按供应商查账单、按用户名查用户这些是必然要用的。不要为了炫技引入用不上的东西。这个体量的系统缓存、消息队列、分布式锁统统不需要引入了只会增加故障点。我见过有人在练手项目里加缓存结果数据不一致的问题查了两天最后发现是缓存没失效。技术选型的标准永远是“当前需求需不需要”而不是“这个东西流不流行”。把测试数据当资产维护。一套覆盖各种边界情况的测试数据比任何文档都有价值。新加一个筛选条件拿测试数据一跑就知道对不对改一个统计逻辑跑一遍就知道结果变没变。我现在的习惯是把测试数据脚本一起纳入版本管理每次改完功能先跑了再说。最后一点写完的东西一定要让别人用一遍。自己用的时候会下意识避开那些不好用的地方别人用的时候专挑你没想到的路径走。一个真实用户点三下就能发现你藏了半天的交互问题这比自测一百遍都有效。