Hono框架中c.json()状态码设置问题的分析与解决

问题背景

在使用Hono框架(版本3.9.1)配合Bun运行时开发API服务时，开发者遇到了一个关于响应状态码设置的异常现象。具体表现为：当通过c.json()方法返回错误响应时，无论设置什么状态码，客户端始终接收到的是200状态码。

问题复现

开发者创建了一个自定义错误类BaseError及其子类ValidationError，并在全局错误处理器中尝试返回带有特定状态码的JSON响应：

app.onError(async (err, c): Promise<Response> => {
  if (err instanceof BaseError) {
    return c.json({ message: err.message }, err.statusCode)
  } else {
    return c.json({ message: "Internal Server Error" }, 500)
  }
})

理论上，当ValidationError被抛出时，应该返回400状态码，但实际观察到的响应状态码始终为200。

排查过程

1. 初步验证：首先确认Hono框架本身在简单场景下能够正确设置状态码
2. 中间件检查：发现项目中使用了bun-compression这个第三方压缩中间件
3. 最小化测试：创建了一个最简单的测试用例：

app.use("*", compress()) // 来自bun-compression
app.get('/', (c) => c.text('Hello Hono!', 201))

测试结果显示即使这样简单的设置，状态码也会被强制改为200

根本原因

经过深入分析，发现问题出在bun-compression中间件的实现上。该中间件在处理响应时，没有正确保留原始响应的状态码信息，而是将所有响应的状态码都重置为200。具体来说，问题出在中间件内部没有正确处理Context对象中的状态码属性。

解决方案

1. 临时解决方案：移除bun-compression中间件，改用Node.js内置的zlib模块实现压缩功能：

// 实现自定义的CompressionStream和DecompressionStream
globalThis.CompressionStream ??= class CompressionStream {
  constructor(format: string) {
    make(this, format === 'deflate' ? zlib.createDeflate() :
      format === 'gzip' ? zlib.createGzip() : zlib.createDeflateRaw())
  }
}

2. 长期解决方案：向bun-compression项目提交PR修复状态码处理问题

经验总结

1. 当遇到框架行为不符合预期时，应该从最简单的测试用例开始验证
2. 中间件可能修改或覆盖框架的默认行为，需要逐一排查
3. 在Bun生态还不完全成熟的情况下，某些功能可能需要自行实现
4. 状态码处理是HTTP响应的关键部分，任何中间件都应该谨慎处理

最佳实践建议

1. 对于关键功能如状态码处理，应该编写单元测试确保行为符合预期
2. 在使用第三方中间件前，应该审查其源代码了解其实现方式
3. 考虑使用更成熟的压缩方案，如Hono官方推荐的中间件
4. 在Bun环境下，可以优先考虑使用Node.js兼容模块来实现缺失功能

这个问题虽然表面上看起来是Hono框架的问题，但实际上揭示了中间件开发中需要注意的状态码处理规范，为开发者提供了宝贵的调试经验。