在开发服务端应用的时候，由于服务端应用本身的特性，其实是没有一个明确的版本的概念。毕竟不需要专门下载，理论上每次都是最新的，所以也没有版本的概念。
但在实际开发调试过程中，我们又的确需要关注版本的概念，因为会影响具体的表现形态，所以就需要有一个前后端协调的版本号概念，来帮助我们更好的定位问题，避免前后端之间的扯皮。
一个比较好的思路是，虽然服务端没有版本号概念，但大部分时候会有一个对应的 Commit ID（毕竟现在开发项目完全不用版本控制工具的还是挺少见的）。所以，你可以选择将 Commit ID 作为版本号，进行输出，从而让协作者知道当前线上跑的版本，便于 debug。
在具体实现时，有两种方式：
1. 将 Commit ID 放在 Header 里
我自己平时会把 Vercel 和 Next.js 提供的 API Route 作为一个简单的 Serverless FaaS 环境来使用，因此一个诉求便是在 API Route 当中返回具体的 Commit ID。而为了避免对代码的侵入，将其放在 Response Header 当中是比较合适的。
而如果你希望和我一样，达成对特定路由下的返回结果添加特定的 Header（比如上面截图中 x-build-sha 就是我添加的 Commit ID 的 Header），则需要借助于 Next.js 提供的自定义 Header 能力。
通过在 next.config.js 当中的 header 属性中添加具体的配置，来实现对特定的路径下添加自定义 Header。
module.exports = {
async headers() {
return [
{
source: '/about',
headers: [
{
key: 'x-custom-header',
value: 'my custom header value',
},
{
key: 'x-another-custom-header',
value: 'my other custom header value',
},
],
},
];
},
};
Code language: JavaScript (javascript)这里面比较关键的是 source 字段，这个字段定义了究竟哪些路由下会返回特定的 Header。比如上面的这段配置就是只给 /about 添加具体的 Header。你可以使用 /:path* 来匹配所有路由，从而实现给所有路由都添加上具体的 Header。
以我为例，我在线上跑的配置实际上是下面这段配置：
/** @type {import('next').NextConfig} */
const nextConfig = {
reactStrictMode: true,
async headers() {
return [
{
source: '/:path*',
headers: [{ key: 'X-Build-SHA', value: process.env.VERCEL_GIT_COMMIT_SHA }]
}
];
}
}
module.exports = nextConfig
Code language: JavaScript (javascript)在上面这段配置中，我给所有的路径都配置了一个 x-build-sha 的 header ，并从进程的变量中提取出 VERCEL_GIT_COMMIT_SHA 变量（这个变量在 Vercel 的部署环境中指向具体的 Commit ID）的值，将其返回。
2. 将 Commit ID 放在 UI 里
除了在 Header 中返回，如果你是需要去 Debug UI 的话，版本号同样重要，这个时候，你可以选择将 Commit ID 放在界面上，从而实现快速找到 Commit ID。
在 Vercel 部署的 Next.js 上，有一批 Next.js 框架所属的环境变量， 可以直接在 UI 当中引用（上面的 VERCEL_GIT_COMMIT_SHA 是不能在 UI 中直接引用的）。
只需要在特定的位置，加入SHA: {process.env.NEXT_PUBLIC_VERCEL_GIT_COMMIT_SHA} ，就可以展示具体的 Commit ID。
（除了 Next.js，其他框架也有类似的框架变量可以使用，你可以根据自己的需求来选择）。
总结
在服务端 Debug 时，将你的 Commit ID 以某种方式返回可以有效的帮助快速定位问题，试着给你的 Next.js 添加上这个 Commit ID，来加速你的问题排查吧～
