要在 Express 中使用 HTML 模板引擎，核心操作只有两步：必须同时配置 app.set('view engine', 'html') 和 app.engine('html', handler)。只设置其中一项无法生效。更复杂的情况是，若希望多个模板引擎并存，例如同时用 EJS 和 art-template 处理同一个 .html 后缀，就不能简单地堆砌配置——因为 app.engine 会静默覆盖前一个设定，而不会给出任何提示，你很难定位问题所在。
先澄清一个常见的误解。
为什么 app.set('view engine', 'html') 不等于“已启用 HTML 引擎”
这个设置其实只做了一件事：告诉 Express，当你在路由中调用 res.render('index') 时，默认去视图目录查找 index.html 文件。至于这个文件如何读取、如何解析，它完全不负责。解析逻辑必须由 app.engine('html', ...) 绑定的回调函数来定义。
如果只配置了 app.set 而漏掉了 app.engine，访问页面时极大概率会报错——要么是“Failed to lookup view”，要么是更隐蔽的“callback is not a function”。所以两者本质上承担着不同的职责：
app.set('view engine', 'html')—— 约定文件名如何查找app.engine('html', require('ejs').__express)—— 规定文件内容如何解析
二者必须保持匹配：app.engine 的第一个参数（扩展名）需要与 view engine 的值一致，否则匹配会失效。
如何让 EJS 和 art-template 同时处理 .html 文件
直接注册两个 app.engine('html', ...) 是行不通的——后注册的会静默覆盖前一个，且不会给出任何警告。正确的做法是利用文件扩展名进行区分，例如让 EJS 处理 .ejs.html 文件，art-template 处理 .art.html 文件：
- 安装所需引擎：
npm install ejs art-template express-art-template - 分别绑定不同的扩展名：
app.engine('ejs.html', require('ejs').__express); app.engine('art.html', require('express-art-template')); - 设置默认引擎为其中之一（如
app.set('view engine', 'ejs.html')），或者在渲染时显式传递扩展名：res.render('page.ejs.html', data)和res.render('page.art.html', data) - 记得确保
views目录下存在对应的文件，例如views/page.ejs.html和views/page.art.html
使用 consolidate 统一接入多引擎的陷阱
consolidate 确实能简化多引擎的接入流程，但在处理 .html 后缀时有一些容易忽略的细节：
- 它内部会将
consolidate.ejs当作函数调用，但 EJS 的__express方法依赖filename参数，而consolidate在某些版本中可能没有透传该参数，导致include或partial失效 - 如果同时将
consolidate.ejs和consolidate.handlebars注册到同一个扩展名（如html），仍然会出现覆盖问题 - 建议的做法是：仅用
consolidate接入一些非主流引擎（如swig、dot），而主流引擎（EJS、Pug、Handlebars）优先使用原生app.engine绑定
真正“共存”的关键：在路由中手动选择引擎
最可控的方式不是依赖扩展名，而是绕过 res.render() 的自动查找机制，在路由里直接调用引擎函数：
- 引入两个引擎：
const ejs = require('ejs')、const template = require('art-template') - 读取模板字符串：
const html1 = fs.readFileSync('./views/page1.html', 'utf8') - 分别渲染：
const result1 = ejs.render(html1, data); const result2 = template.render('./views/page2.html', data); - 使用
res.send(result1)或res.type('html').send(...)输出结果 - 这样完全脱离 Express 的视图系统，自由度最高，也最容易调试——但代价是失去
layout、partials等框架层面的功能
归根结底，多引擎共存并非某个配置开关能解决的，而是路径、扩展名和调用时机三者的组合决策。最容易忽略的就是 app.engine 的覆盖行为——它不报错，只是静默替换。遇到问题时，很多人往往以为是模板语法写错了，其实根本就没走到预期的那个引擎。