Express 渲染 index. 报 ERR_INVALID_ARG_VALUE：空模块名来自末尾的点

项目已经设置 EJS，app.render('index', ...) 可以工作，模板名写成 index. 后却抛出：

TypeError [ERR_INVALID_ARG_VALUE]: The argument 'id' must be a non-empty string. Received ''

这里的 id 是内部加载模块时的参数，不是模板中的业务 ID。Express 5.3.0 的视图构造仍可能在这个形态中尝试加载空模块名；修改数据库字段或往模板参数里补一个 id 都没有作用。

单独的点也会被识别为扩展名

Node 的 path.extname('index.') 返回 '.'。Express 看见扩展名非空，就不会再按默认引擎为名字追加 .ejs。如果没有为 '.' 注册引擎，接下来去掉扩展名开头的点，得到空字符串，再交给 require()，于是出现“模块 id 不能为空”。

这条路径发生在模板文件查找之前，所以即使 views/index.ejs 确实存在，错误也不会因此消失。它不同于正常的 Failed to lookup view：后者说明引擎已选定，但找不到目标视图。

核对实际传给 render 的字符串，尤其是从内部配置、拼接逻辑或重命名中产生的末尾点。诊断只需保留模板名和必要调用栈，不必输出传给模板的用户资料。

修正受控模板名，不要修 require 的参数

如果模板确实是 index.ejs，可以使用省略扩展名的 index，或明确的 index.ejs。下面是已有 EJS 配置中的片段：

app.set('view engine', 'ejs');

app.render('index', { title: 'Home' }, (error, html) => {
  if (error) {
    // 交给应用原有的错误处理流程
    return;
  }
  // 使用已经渲染好的 html
});

它假设项目已经安装 EJS，views 指向实际模板目录。注释处要接原有错误记录与输出逻辑，不是要求应用悄悄吞掉异常。

对已有的固定模板映射修正具体条目即可，不要对任意输入统一“去掉末尾所有点”后再渲染。点可以是合法文件名的一部分，盲目清理可能把请求导向另一个模板。更不要将 URL 参数、查询串或请求体直接当成视图名；由应用维护允许使用的模板名称，并继续执行原有访问控制。

callback 未运行，异常也可能已同步抛出

在这条视图构造路径中，app.render() 还没进入正常模板渲染回调就可能抛错。因此，单独给 callback 增加日志，不一定能捕获它。

路由中的 res.render() 与应用直接调用 app.render() 的错误接收方式也应区分。项目若直接调用 app.render()，应在自己的调用边界保留同步异常处理，同时继续处理 callback 报告的渲染错误；不能把 callback 存在理解为所有错误一定只从那里返回。

到 2026 年 10 月 23 日，正式 5.3.0 的相关实现仍保留上述扩展名处理，不应因为有一个处理建议就认定某个正式版已经修复。修正自己的模板名后，验证原页面确实得到预期 HTML，正常不存在的视图仍走原错误分支，并确认模板入口仍由应用控制。不要改 require()、注册空引擎或给所有未知扩展名兜底为 EJS 来掩盖错误名字。