Kratos做博客系统需严格遵循默认结构：proto必须置于api/下并带HTTP选项，registry配置须完整且显式加载，data层错误必须冒泡至initApp，BlogHTTPServer需手动注册到http.Server。
Kratos 框架做博客系统，不是“能不能”，而是“怎么避开默认结构的坑快速跑通核心链路”。直接上手写 Post 服务，90% 的人卡在目录职责错位、proto 生成断裂、或 registry 配置空转——这些都不是框架问题，是项目结构理解偏差导致的。
proto 定义不放在 api/ 下，kratos proto client 就不会生成代码
很多人把 post.proto 放在 internal/biz/ 或自己建的 proto/ 目录，结果执行 kratos proto client 后啥也没生成。Kratos 的代码生成只扫描 api/ 子目录下的 .proto 文件，且要求路径符合包名约定。
-
api/blog/v1/post.proto对应 Go 包名blogv1，生成路径为api/blog/v1/ - service 方法必须带
option (google.api.http) = { ... };才能生成 HTTP 路由（哪怕你只用 gRPC，也建议加上，方便后期扩展） - 别手动改
gen.go或挪动生成文件：下次kratos proto client会覆盖，所有业务逻辑写在internal/层
启动时 registry 配置为空，srv := service.New(srvConf) 却不报错
这是最隐蔽的坑：服务注册看似成功，但 Consul/Etcd 实际没连上，registry 字段为空或配置项拼错（比如写成 regitry），service.New 不 panic，只是静默跳过注册。结果其他服务根本发现不了它。
- 检查
configs/config.yaml中registry:下的consul:是否有address和scheme，值不能是空字符串或注释掉 - 启动加
-conf configs/config.yaml，别依赖默认路径；用log.NewHelper(logger).Infof("registry: %+v", c.Registry)打印配置确认加载 - Consul 本地调试建议用
docker run -d -p 8500:8500 consul，避免端口或 ACL 拦截
blog 服务要查 MySQL，但 data 层初始化失败却没暴露错误
常见现象：程序启动日志显示 start http server，但一调接口就 500 + 空日志。根源往往是 data.NewPostData 里 sql.Open 失败，但被 err != nil 后直接 return，没传给上层 init 函数。
-
data层构造函数必须返回error，并在internal/server/server.go的initApp中显式检查，例如：if err := data.Init(); err != nil { panic(err) } - MySQL DSN 建议用
user:pass@tcp(127.0.0.1:3306)/dbname?parseTime=true&loc=Local，&要 URL 编码为&，否则解析失败静默丢弃 - Ent/GORM 初始化后，立刻执行
db.PingContext(ctx)，比等第一个查询超时更早发现问题
前端请求 404，不是路由没配，是 server/http.go 没挂载 BlogHTTPServer
生成的 server/http.go 默认只注册了 HelloWorldHTTPServer，你新增了 BlogHTTPServer，但忘了在 newHTTPServer 函数里把它加进 http.Server 的 Handler 链里。
- 找到
internal/server/http.go中的newHTTPServer，确认h := &handler{...}后是否调用了h.RegisterBlogHTTPServer(...) - 注册顺序影响中间件生效：如果你加了 JWT 中间件，必须在
h.RegisterBlogHTTPServer之前调用h.Use(...) - 用
curl -v http://localhost:8000/q/health测试基础路由通不通，排除网关或反向代理干扰
真正卡住人的从来不是 Kratos 多难，而是它把「结构约束」藏在约定里——比如 api/ 是唯一 proto 入口、registry 配置字段名大小写敏感、data 层 error 必须冒泡到 initApp。这些点不亲手踩一遍，看十遍文档也没用。
