从零实现类Express Node服务器：请教Express回调机制及自研方案缺陷

我的实现思路与测试结果 #

我正在从零实现一个类似ExpressJS的Node服务器，设计思路是：将多个回调函数以请求URL和请求方法为键，存入对应数组关联到请求处理器中。当收到请求时，调用对应回调数组的forEach方法，自动执行所有回调。

该方案在测试GET、POST、PUT等多种请求方法及不同端点时均能正常运行。

我的问题 #

• 既然我的方案无需next()函数即可处理任意数量的回调，那么ExpressJS采用何种方式存储同一方法下的多个回调，为何需要通过next()函数来触发后续回调？
• 我的方案存在哪些弊端？

我的实现代码 #

const http = require('http')

class MyServer{
    constructor(){
        this.obj = {}
        this.verbsObj = {
            'GET': [],
            'POST': [],
            'PUT': [],
            'DELETE': [],
        }
    }

    get(endpoint, ...args){
        this.verbsObj['GET'].push(...args)
        this.obj[endpoint] = {...this.verbsObj}
    }

    post(endpoint, ...args){
        this.verbsObj['POST'].push(...args)
        this.obj[endpoint] = {...this.verbsObj}
    }

    createServer(){
        const server = http.createServer()
        server.on('request', (req, res) => {
            console.log(this.obj)
            this.obj[req.url][req.method].forEach(cb => {
                cb(req, res)
            })
        })
        return server
    }

    listen(port, hostname, cb){
        this.createServer().listen(port, hostname, cb)
    }

}

const app = new MyServer()

app.get('/', (req, res) => {console.log(req.method, req.url)}, (req, res) => {res.end('Hello World')})
app.post('/', (req, res) => {console.log(req.method, req.url); res.end('post data')})


app.listen(3000, 'localhost', () => {console.log('server running')})

回答 #

关于Express的存储方式与next()的作用 #

Express把同一路由（请求方法+匹配路径）下的回调/中间件，存储在一个中间件栈结构里，每个回调都是栈的一个元素。它必须用next()触发后续回调，核心是为了给开发者提供流程控制权，主要场景包括：

• 中断流程：比如权限校验中间件，如果校验不通过，直接返回错误响应，不调用next()，后续回调就不会执行，避免无效操作；
• 异步场景适配：很多中间件是异步的（比如读取数据库、调用第三方接口），必须等异步操作完成后手动调用next()，才能保证后续回调拿到正确的上下文数据；
• 跨路由/全局中间件流转：Express支持全局中间件（比如日志、请求体解析）、模糊路由匹配（如/user/:id），next()能让请求在不同中间件、不同路由之间按预期流转，而不是局限在某个固定端点的回调数组里。

你的方案存在的弊端 #

1. 异步处理失效：如果回调包含异步操作（如文件读取、数据库查询），forEach会同步执行所有回调，异步操作还没完成，后续回调就已经运行，会导致数据不一致或逻辑错误；
2. 无法中断回调链：只要匹配到URL和方法，所有回调都会强制执行，没法在某个回调里终止流程（比如参数校验失败时直接返回错误，不让后续业务逻辑回调执行）；
3. 路由匹配能力缺失：仅支持精确URL匹配，不支持Express常用的参数路由（/user/:id）、通配符（/user/*）、正则匹配，也无法添加全局中间件；
4. 回调污染问题：你的verbsObj是实例共享的，每次调用get/post都会把整个verbsObj复制到对应端点，导致不同端点的同一方法回调互相污染——比如给/加了GET回调后，再给/api加POST回调，/api的GET数组里也会包含/的GET回调，逻辑完全错误；
5. 无错误/404处理：如果请求的URL或方法不存在于this.obj中，会直接抛出报错，没有默认的404响应或错误捕获逻辑。

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