Express中在projects静态中间件前执行自定义函数的生产环境异常

1. 修复自定义中间件的核心错误 #

你的addView中间件存在**重复调用next()**的问题，这会导致Express抛出"响应头已发送"的错误，也是生产环境异常的关键原因之一。同时，原代码依赖req.originalUrl解析路径的方式在生产环境（可能带反向代理前缀）容易失效，改用req.path更可靠。修改后的代码如下：

const addView = async (req, res, next) => {
    // 匹配/projects下的xxx/index.htm路径，获取文件夹名称
    const pathMatch = req.path.match(/^\/([^\/]+)\/index\.htm$/);
    if (pathMatch) {
        try {
            const folder = pathMatch[1];
            const project = await models.projects.findOne({ where: { folder } });

            if (project) {
                await models.projects.increment({ views: 1 }, { where: { id: project.id } });
            } else {
                // 触发错误处理后立即return，避免执行后续的next()
                return next('Project not found');
            }
        } catch (err) {
            console.log(`Error: ${err}`);
            // 捕获异常后return，避免重复调用next()
            return next(err);
        }
    }
    // 仅在无错误分支时调用一次next()，进入静态文件处理
    next();
}

2. 确保中间件执行顺序 #

保持addView在express.static之前挂载，这样所有匹配/projects的请求都会先经过自定义中间件，再进入静态文件处理流程：

app.use('/projects', ProjectsRoute.addView, express.static(path.join(__dirname, '/resources/projects')));

3. 本地与生产环境差异的原因 #

• 路径解析失效：生产环境中请求URL可能带有反向代理前缀（如/app/projects/xxx），原代码通过req.originalUrl.split('/')[3]获取文件名的逻辑会完全失效，改用req.path（相对于挂载点/projects的路径）能避免这个问题。
• 重复调用next()：本地环境可能未触发else或catch分支，因此没暴露重复调用next()的问题；生产环境触发错误分支后，多次调用next()会导致响应逻辑混乱，表现为自定义中间件仅在文件不存在时执行。

额外优化方案 #

如果仅需要针对index.htm请求统计访问量，可以用路由参数精准匹配，减少不必要的路径判断：

// 仅对/projects/:folder/index.htm的请求执行统计逻辑
app.use('/projects/:folder/index.htm', ProjectsRoute.addView);
// 挂载静态文件中间件处理所有/projects下的请求
app.use('/projects', express.static(path.join(__dirname, '/resources/projects')));

内容的提问来源于stack exchange，提问作者Leandro Melo