在网站开发框架中，中间件是处理请求和响应的核心管道组件，而请求校验与日志记录是两个最基础也最关键的中间件功能。简单来说，请求校验中间件负责在业务逻辑执行前拦截非法、格式错误或缺少必要参数的请求，直接返回错误响应；日志记录中间件则负责在请求进入和离开时自动记录关键信息，包括请求路径、方法、耗时、状态码、用户IP等，方便后续排查问题和性能分析。这两个功能通常以独立中间件的形式实现，然后在框架的管道中按顺序注册，形成一个可复用、可维护的基础架构层。
很多开发者在项目初期会把校验逻辑和日志代码散落在各个控制器或业务函数里，导致代码重复、维护困难、出错难以追踪。通过中间件统一实现，可以把这些横切关注点从业务代码中剥离出来，让每个接口只关注自身的业务逻辑。下面我会从设计思路、具体实现、代码示例、最佳实践四个维度，把这件事讲透。
一、为什么必须用中间件来做这两件事首先要理解中间件的本质：它是一个在请求到达最终处理函数之前、以及响应返回客户端之前执行的处理单元。每个中间件可以选择继续传递请求给下一个中间件，也可以选择直接中断并返回响应。这种机制天然适合做两件事——第一，在最前面拦截不合法请求；第二，在请求的入口和出口都记录信息。
从架构角度看，请求校验和日志记录属于"横切关注点"，它们不属于任何一个具体的业务模块，但几乎每个接口都需要。如果不用中间件，你就得在每个接口函数开头写一遍参数检查，在每个接口函数结尾写一遍日志输出，代码量膨胀不说，一旦校验规则变了，你得改几十个地方。中间件把这些逻辑集中到一处，改一处就全局生效。
另外，从性能和安全角度看，请求校验中间件放在管道最前面，可以在请求到达数据库查询、外部API调用等耗时操作之前就把非法请求挡掉，节省服务器资源。日志记录中间件放在管道两端，可以精确统计每个请求的处理耗时，帮助你发现性能瓶颈。
二、请求校验中间件的设计与实现请求校验中间件的核心任务是检查请求是否满足预设规则。常见的校验内容包括：请求体格式是否为JSON、必填字段是否存在、字段类型是否正确、参数值是否在合理范围内、是否携带了必要的认证信息等。
设计上，建议采用"规则配置 + 通用校验器"的模式。你可以定义一套校验规则对象，描述每个接口需要检查什么，然后中间件根据当前路由匹配到的规则自动执行校验。这样不同接口可以有不同的校验强度，而中间件本身是通用的。
以下是一个基于Node.js Express风格的请求校验中间件示例：
// 校验规则定义
const validationRules = {
'POST /api/users': {
body: {
username: { required: true, type: 'string', minLength: 3 },
email: { required: true, type: 'email' },
age: { required: false, type: 'number', min: 0, max: 150 }
}
},
'PUT /api/users/:id': {
params: { id: { required: true, type: 'number' } },
body: {
username: { required: false, type: 'string' },
email: { required: false, type: 'email' }
}
}
};
// 通用校验中间件
function validationMiddleware(req, res, next) {
const routeKey = `${req.method} ${req.path}`;
const rules = validationRules[routeKey];
if (!rules) {
return next(); // 没有定义规则的路由直接放行
}
const errors = [];
// 校验 params
if (rules.params) {
for (const [key, rule] of Object.entries(rules.params)) {
const value = req.params[key];
if (rule.required && (value === undefined || value === null)) {
errors.push(`参数 ${key} 为必填项`);
}
if (value !== undefined && rule.type === 'number' && isNaN(Number(value))) {
errors.push(`参数 ${key} 必须为数字`);
}
}
}
// 校验 body
if (rules.body) {
for (const [key, rule] of Object.entries(rules.body)) {
const value = req.body?.[key];
if (rule.required && (value === undefined || value === null || value === '')) {
errors.push(`字段 ${key} 为必填项`);
}
if (value !== undefined && rule.type === 'email' && !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value)) {
errors.push(`字段 ${key} 格式不正确`);
}
if (value !== undefined && rule.type === 'number' && (isNaN(Number(value)) || Number(value) < rule.min || Number(value) > rule.max)) {
errors.push(`字段 ${key} 数值超出范围`);
}
}
}
if (errors.length > 0) {
return res.status(400).json({
code: 400,
message: '请求参数校验失败',
errors: errors
});
}
next();
}
上面这段代码的关键在于：它不是硬编码在某个接口里的，而是通过路由匹配动态获取规则。你只需要维护一个规则表，新增接口时加一条规则就行。校验失败时统一返回400状态码和结构化的错误信息，前端可以直接解析展示。
在实际项目中，你还可以引入更成熟的校验库，比如Joi、Zod、class-validator等，它们提供了更丰富的规则定义和更好的错误信息生成。中间件的职责就是调用这些库的校验函数，然后根据结果决定是放行还是拦截。
三、日志记录中间件的设计与实现日志记录中间件要做的事情比校验更简单，但要做好却不容易。核心需求是：记录请求开始时间、请求方法、路径、IP、User-Agent、请求体摘要；记录响应状态码、响应耗时；如果出错还要记录错误堆栈。关键是要控制日志的详细程度，避免在生产环境输出过多敏感信息或过大的日志文件。
设计上，建议采用"请求进入时记录开始时间，响应发出时计算耗时并输出"的双阶段模式。同时支持不同环境输出不同级别的日志，开发环境输出DEBUG级别包含完整请求体，生产环境只输出INFO级别只记录关键字段。
// 日志记录中间件
function loggerMiddleware(req, res, next) {
const startTime = Date.now();
const startTimestamp = new Date().toISOString();
const requestId = req.headers['x-request-id'] || generateRequestId();
// 记录请求信息
const logEntry = {
timestamp: startTimestamp,
requestId: requestId,
method: req.method,
path: req.path,
ip: req.ip || req.connection.remoteAddress,
userAgent: req.get('user-agent'),
contentType: req.get('content-type')
};
// 开发环境记录请求体摘要
if (process.env.NODE_ENV === 'development' && req.body && Object.keys(req.body).length > 0) {
logEntry.body = JSON.stringify(req.body).substring(0, 500);
}
console.log(`[REQUEST] ${JSON.stringify(logEntry)}`);
// 拦截响应的 finish 事件
res.on('finish', () => {
const duration = Date.now() - startTime;
const responseLog = {
timestamp: new Date().toISOString(),
requestId: requestId,
method: req.method,
path: req.path,
statusCode: res.statusCode,
duration: `${duration}ms`
};
if (res.statusCode >= 500) {
responseLog.level = 'ERROR';
} else if (res.statusCode >= 400) {
responseLog.level = 'WARN';
} else {
responseLog.level = 'INFO';
}
console.log(`[RESPONSE] ${JSON.stringify(responseLog)}`);
});
// 捕获异常
res.on('error', (err) => {
const duration = Date.now() - startTime;
console.error(`[ERROR] requestId=${requestId} path=${req.path} duration=${duration}ms error=${err.message}`);
});
next();
}
function generateRequestId() {
return `${Date.now()}-${Math.random().toString(36).substring(2, 10)}`;
}
这段代码实现了几个重要的工程细节：第一，生成或提取唯一的请求ID，方便在分布式系统中追踪一条请求的完整链路；第二，通过监听res.on('finish')事件来确保在响应真正发送完毕后才记录耗时，而不是在中间件执行完就记录；第三，根据状态码自动标记日志级别，便于后续用日志分析工具做过滤和告警。
在生产环境中，建议不要直接用console.log输出日志，而是接入结构化日志系统，比如输出JSON格式到文件或日志收集服务，这样后续可以用ELK、Loki等工具做查询和可视化分析。
四、中间件的注册顺序与管道组合中间件的执行顺序非常重要。一般来说，日志记录中间件应该放在最外层，包裹住所有其他中间件，这样它可以记录整个请求的总耗时。请求校验中间件应该放在业务中间件之前，确保只有合法请求才能进入后续处理。认证中间件通常放在校验之后、业务之前。
一个典型的管道注册顺序如下：
app.use(loggerMiddleware); // 最外层：记录总耗时 app.use(authMiddleware); // 认证 app.use(validationMiddleware); // 参数校验 app.use(rateLimitMiddleware); // 限流（可选） app.use(router); // 路由和业务逻辑
需要注意的是，如果某个中间件调用了next()并传递了错误，后续中间件应该能够捕获并处理。Express框架中，如果中间件有四个参数(err, req, res, next)，框架会自动将其识别为错误处理中间件。你可以专门写一个错误处理中间件来统一记录异常日志并返回友好的错误响应。
五、进阶优化与注意事项第一，不要在校验中间件里做数据库查询或外部调用。校验只应该检查请求本身携带的信息，比如参数格式、必填项、长度范围等。涉及数据存在性的校验（比如用户名是否已注册）应该放在业务逻辑层。
第二，日志记录要注意脱敏。生产环境中绝对不能记录密码、token、身份证号等敏感字段。可以在中间件里加一个过滤函数，在输出前把敏感字段替换为星号或直接删除。
第三，对于大文件上传的请求，不要把整个请求体都读入内存再记录。可以只记录文件名、大小、类型等元信息。很多框架提供了流式处理的方式，可以在不完整读取请求体的情况下做校验和日志。
第四，考虑异步校验场景。如果你的校验规则需要查数据库（比如验证邀请码是否有效），中间件需要变成异步的，使用async/await或者返回Promise。但要注意错误处理，异步中间件出错时要用try/catch包裹并调用next(err)。
第五，在高并发场景下，同步写日志可能成为性能瓶颈。可以考虑使用异步日志写入、批量刷新、或者将日志发送到消息队列由专门的服务处理。不要让日志IO阻塞请求处理的主流程。
六、总结请求校验和日志记录是网站开发框架中最基础的两个中间件功能，但做好它们需要理解中间件管道机制、掌握规则驱动的设计思路、注意性能和安全细节。通过将这两个功能从业务代码中抽离出来，你的项目会变得更整洁、更易维护、更容易排查问题。核心原则就是：校验放前面挡非法请求，日志放两头记关键信息，中间件按顺序组合，规则集中管理。掌握了这套方法，不管你用什么语言、什么框架，都能快速搭建起稳固的请求处理基础层。
