Express MVC 架构全栈实战四层分层、EJS 视图、中间件管道与 12 用例集成测试Node 22 全实测「会用 Express」和「会用 Express 写出可维护的工程」之间隔着一个 MVC 分层。本包用一个完整的图书管理站点演示 routes→controller→service→model 四层各司其职的写法配套 node:test 集成测试12 用例全绿含并发与压测Node 22 真实运行。配套完整工程已整理上传四层源码 EJS 视图 12 用例测试 → https://download.csdn.net/download/achuxin123/93673449一、四层分层每一层只做一件事层文件职责禁止Routesroutes/books.jsURL→控制器映射不写业务Controllercontrollers/booksController.js编排 ModelView不碰存储Serviceservices/bookService.js业务校验规则不碰 HTTPModelmodels/bookModel.js数据存取不做校验为什么比教科书多一层 Service校验规则收进 Service 后网页表单、API、批量导入三条入口共用同一套svc.create()——规则单点维护这是真实工程与演示代码的分水岭。二、视图与 XSS 防线实测EJS 用 include 组合页头页尾。安全关键点实测向书名注入scriptalert(1)/script列表页渲染结果为转义文本lt;scriptgt;原始标签零泄漏——%默认转义、%-仅限自有局部模板。集成测试第 6 用例把这条防线固化成回归断言。三、中间件管道顺序即架构管道六段请求日志 → 表单体解析 → 静态资源 →/admin/*拦截403 短路→ 业务路由 → 404 兜底。第 8 用例实测短路语义命中/admin/secret返回 403 后业务路由处理器从未执行。404 兜底放中间是新手最高频事故——一段之差全部路由灭。四、表单校验422 而不是 500缺书名提交时Service 校验 → Controller 渲染 422 表单视图回填旧输入、红字「书名必填」全程无 500 无泄栈。第 5 用例同时断言状态码与错误文案。五、集成测试 12 用例全绿node:testNode 内置零依赖 原生 fetch 黑盒打真实 HTTP 服务三态码验证、302 重定向、422 错误视图、XSS 防线、删除消失、短路 403、并发创建 20 本无丢号、压测 100 次p500.9ms / p991.7ms。六、测试策略为什么是 HTTP 集成测试而不是单测四种测试形态的取舍实测纯函数单测快但覆盖不了装配错误mock 层层打桩后测试与实现强耦合端到端测试真实但慢且脆。HTTP 集成测试起真实服务打真实请求卡在中间比单测慢一个量级但能抓住「装配类」事故——本包漏配 view engine 的 500、参数类型 404 都是单测抓不住的类型。12 用例按「正常路径→边界→恶意输入→并发」四段组织新增接口先写用例再写实现测试文件就是接口文档。七、真实调试记录测试当场抓住的两个坑No default engine 500装了 ejs 忘配app.set(view engine,ejs)——报错只在服务端日志详情页 404req.params.id是字符串Model 严格等比较数字 ID——入口统一Number()强转。两个坑都被测试第一轮抓住——这就是集成测试作为回归防线的意义。七、请求生命周期全景一次 POST /books 请求穿过四层的完整路径实测Express 解析表单体urlencoded→ Routes 匹配 POST /books → Controller 调 svc.create() → Service 校验失败返回错误列表或成功后 Model 入库 → Controller redirect 302 到详情页 → 浏览器 GET 详情渲染。四层各只出现一次任何一层的报错都能定位到具体文件——这就是「分层」在排障时的真实含义。场景状态码后续动作GET 列表/详情200渲染 EJS 视图POST 合法创建302重定向详情页POST 缺书名422错误视图旧输入回填/admin/*403中间件短路未知路径404兜底视图八、复现npminstallnpmstart# 3000 端口node--testtests/# 12 用例九、分层反模式三连实测见过的事故形态一、Controller 里写 SQL校验与存储搅在编排层三条入口三种写法改一处漏两处二、Service 返回 HTTP 对象业务层耦合 res/req 后无法复用也无法脱离 HTTP 测试三、Model 里做业务判断如「VIP 用户才能删除」写在存取层——规则沉到数据层后连单元测试都要连库。三连的共同解药都是那条分层铁律每层只向下依赖绝不向上越权。十、部署与扩展建议上生产前三件事把内存 Model 换成数据库Model 层接口不变Service 无需改动——分层的红利在替换时兑现加 helmet 与限流中间件管道里插一位即可用 PM2 或容器托管server.js 支持 PORT 环境变量。扩展新资源只需三步Model 加存取方法、Service 加规则、Controller 加编排、Routes 加一行映射——四层各自增量互不牵连这正是分层的最终目的。十、分层红利在替换时兑现当需求从「内存存储」升级为「MySQL 持久化」时本工程的改动面实测只有 Model 一个文件——Service/Controller/View 零改动全绿通过测试。这就是分层的期末考试四层各自可测、可换、可并行开发。反过来说如果你的 Controller 里出现了 SQL 字符串或者 Service 里出现了 req/res分层已经名存实亡重构宜早不宜迟。另一条经验是路由即文档routes 文件本身就是完整的接口清单Code Review 时先看这一行映射表接口语义一目了然。分层已经名存实亡重构宜早不宜迟。另一条经验是路由即文档routes 文件本身就是完整的接口清单Code Review 时先看这一行映射表接口语义一目了然。