为何CORS中间件调用需加括号而自定义auth中间件加括号报错

两者的本质差异是函数定位完全不同：

• 你自定义的auth是符合Express规范的「请求处理中间件本体」
• 引入的cors是用来生成中间件的「工厂函数」，本身不直接处理请求

1. 普通自定义中间件的运行逻辑 #

你写的auth函数本身签名就满足Express中间件要求：固定接收(req, res, next)三个参数，内部写鉴权逻辑。
路由注册时直接把函数引用auth传给app.get，等匹配到对应请求时，Express会自动给这个函数注入请求、响应、next回调三个参数，按顺序执行逻辑：

// auth本身就是要执行的请求处理逻辑
function auth(req, res, next) {
  const token = req.headers.authorization
  if (!token) return res.sendStatus(401)
  next()
}

// 直接传函数引用即可，请求进来才会执行
app.get('/products/:id', auth, function (req, res, next) {
  res.json({msg: 'This is an authorized Route'})
})

如果加了括号写auth()，等于在服务启动、注册路由的阶段就立刻执行了auth函数，这时候根本没有实际请求进来，拿不到req/res/next参数，要么提前执行逻辑出问题，要么直接报错。

2. CORS中间件的运行逻辑 #

cors包导出的不是直接处理请求的中间件，而是一个「中间件生产函数」：

1. 你调用cors(配置项)的时候，会在注册路由阶段立刻执行外层函数，预处理你传入的CORS规则（比如允许的域名、是否允许携带Cookie、允许的请求方法等）
2. 外层函数执行完，会返回一个符合Express规范的(req, res, next) => {}格式的真正中间件，这个返回的函数才是请求进来时实际执行的CORS逻辑

cors的简化内部实现大概是这样：

// cors包导出的外层工厂函数
function cors(userOptions) {
  // 调用cors()时立刻执行：合并默认配置、预处理规则
  const finalOptions = Object.assign({
    origin: "*",
    credentials: false
  }, userOptions)

  // 返回的才是真正处理请求的CORS中间件
  return function realCorsMiddleware(req, res, next) {
    // 给响应加CORS相关头、处理OPTIONS预检请求
    res.setHeader("Access-Control-Allow-Origin", finalOptions.origin)
    res.setHeader("Access-Control-Allow-Credentials", finalOptions.credentials)
    // 其余CORS逻辑...
    next()
  }
}

所以官方示例里写cors()，本质是先执行工厂函数拿到真正的中间件，再传给路由，和你直接传auth的效果是一样的——传给Express的都是符合签名要求的请求处理函数。如果直接传cors不加括号，Express会把外层工厂函数当成中间件执行，传入的req/res/next会被识别为配置参数，既不会正确处理CORS逻辑，也不会调用next()，请求会直接卡住。

这种工厂函数的设计是Express生态第三方中间件的常见模式，好处是可以通过传入不同配置，灵活生成不同规则的中间件实例，不用为每一种规则单独写中间件逻辑。

内容的提问来源于stack exchange，提问作者DEV MEENA