我前端使用ant design vue pro框架，后端使用kratos框架开发。因为之前也解决过跨域问题，正常是在后端的http请求中加入中间件，设置跨域需要通过的字段即可，代码如下所示：

func NewHTTPServer(c *conf.Server, s *conf.Secret, rolesm *service.RolesManageService, tracer trace.TracerProvider, logger log.Logger) *http.Server {
	var opts = []http.ServerOption{
		http.Middleware(
			recovery.Recovery(),
			tracing.Server(tracing.WithTracerProvider(tracer)),
			logging.Server(logger),
			validate.Validator(),
			metadata.Server(),
			LocalHttpRequestMiddleware(),
			selector.Server(
				jwt.Server(
					func(token *jwtv5.Token) (interface{}, error) {
						return []byte(s.Bigantauthen), nil
					}, jwt.WithSigningMethod(jwtv5.SigningMethodHS256)),
			).Match(NewWhiteListMatcher()).Build(),
		),
// 下面需要解决跨域问题的字段
		http.Filter(handlers.CORS(
			handlers.AllowedHeaders([]string{"X-Requested-With", "Content-Type", "Authorization"}),
			handlers.AllowedMethods([]string{"GET", "POST", "HEAD", "OPTIONS", "PUT", "DELETE"}),
			handlers.AllowedOrigins([]string{"*"}),
			handlers.AllowCredentials(), // 允许携带凭证（如 cookies）
		)

之前可以正常运行，但是我在前端设计时，在登录请求后的请求中，在头部信息加入了一个自定义字段，为了后端获取后检索缓存信息，这样就不用反复从数据库查询了。想法是这个样子但是测试中就开始报错了，报的是跨域错误，代码如下。

Access to XMLHttpRequest at 'http://localhost:8002/user/info' from origin 'http://localhost:8000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

但奇怪的是前面login的请求可以正常通过，后面的userinfo请求就拒绝了。我就在想，要是跨域问题，就应该所有请求都拒绝呀，不应该选择性拒绝呀，而且我后端也没做相关的请求过滤的语句，报错的有点蹊跷。

我于是开始问DeepSeek。它给我的回答和之前设置的内容一样。要不就在前端做代理，如下代码所示，对vue.config.js做相关修改。

module.exports = {
    devServer: {
        proxy: {
            '/api': {
                target: 'http://localhost:8002', // 后端地址
                changeOrigin: true,
                pathRewrite: {
                    '^/api': ''
                }
            }
        }
    }
}

但是，我这里不想修改前端，因为要是实际部署，如果跨域问题是出在后端，部署之后bug还会存在。于是我把网页控制台的报错信息截图发给DeepSeek，让它帮忙给分析以下，并且把我的疑问也一同发给它。后来，在它给的答案中无意中发现了一条内容，引起了我的注意。就是如下图所示的内容：

handlers.AllowedHeaders([]string{"X-Requested-With", "Content-Type", "Authorization", "Your-Custom-Header"}),

这里有一个"Your-Custom-Header"你自定义的头。哦！我恍然大悟，可能是我在userinfo中在头部自定义的头部信息的原因。为了验证我的猜测，我把头部自定义的头部信息删除后，再去测试，发现可以通过了，跨域报错没有了，这证明了我的猜测是正确的。于是在服务端做了如下调整：

http.Filter(handlers.CORS(
			handlers.AllowedHeaders([]string{"X-Requested-With", "Content-Type", "Authorization", "Kt"}), //这里需要添加自定义的头部信息如Kt
			handlers.AllowedMethods([]string{"GET", "POST", "HEAD", "OPTIONS", "PUT", "DELETE"}),
			handlers.AllowedOrigins([]string{"*"}),
			handlers.AllowCredentials(), // 允许携带凭证（如 cookies）
		)

将前端自定义的头部键字段：Kt  添加在了cors请求里，再去测试，可以正常运行了。

总结，DeepSeek真的很强大，你完全可以将它作为你的一个老师，有问有答，按照思维逻辑循序递进，它不但可以读懂你的问题，代码，它还能读懂截图。对于程序员学习和工作都有极大的帮助，用好了真可谓事半功倍。当然，网上也有很多直接用DeepSeek写代码的，这个虽然效率更高，但对于新手来说，我个人建议起初不要那么使用。因为DeepSeek直接写代码，也会和人类一样，会出错，有各种bug，并且人机交流过程中，它做的未必真的就是你想要的。你要看懂它写的程序，并且把bug找出来，告诉它如何修改，这需要你自身有一定功底，在内功没练好之前，你很难驾驭有DeepSeek自动生成一整个正确的项目。不如从简单问题着手，分单一模块功能交给DeepSeek编写，然后自己完成单元测试，然后逐步的组合，直至完成整个项目。这样，从中你也得到了学习和锻炼，也明白了整个过程和细节。不是由AI支配你，而是你使用了AI。我认为这才是好的使用AI的方式。