kratos new 是启动 Kratos 微服务项目的唯一正确起点，必须确保 protoc≥3.21、protoc-gen-go=v1.31+、GO111MODULE=on 且 GOPROXY 正确；生成后需验证 conf.proto 存在及 wire.go 中 InitializeApp 函数声明。
kratos new 是你启动 Kratos 微服务项目的唯一正确起点，别手动建目录、复制配置或改 go.mod —— 那些操作不仅慢，而且极易破坏 Kratos 的依赖注入（wire.go）、协议生成（api/ 下的 .pb.go）和配置加载（configs/config.yaml）三者之间的契约关系。
用 kratos new 生成项目前必须确认的三件事
不是所有 Go 环境都能直接跑通 kratos new，常见失败根本原因就在这三项没对齐：
-
protoc和protoc-gen-go版本不匹配：Kratos v2.x 要求protoc≥ 3.21，protoc-gen-go必须是 v1.31+（不是最新版！v1.32+ 会因google.golang.org/protobuf接口变更导致api/生成失败） -
GO111MODULE=on未启用：Kratos 项目强依赖模块化，关闭时go mod download会漏掉google.golang.org/grpc/cmd/protoc-gen-go-grpc等关键工具 -
GOPROXY不可用：国内环境若未设为https://goproxy.cn,direct，kratos new会在拉取模板时卡死在github.com/go-kratos/kratos-layout这一步，超时后静默失败，只留下空文件夹
kratos new 生成后立刻要验证的两个关键点
项目目录生成完成 ≠ 可运行。很多团队卡在“本地跑不起来”，其实问题出在生成后没做这两项检查：
- 确认
internal/conf/conf.proto是否存在且被internal/conf/conf.pb.go正确引用：Kratos 的配置加载机制依赖该文件生成结构体，缺失会导致conf.Load()panic 报错"unknown field 'xxx' in conf.Config" - 检查
cmd/server/wire.go中是否已声明InitializeApp函数：这是 Wire 依赖注入的入口，若被误删或未生成，kratos run会报"undefined: InitializeApp"，而不是更友好的提示
为什么不要用 blades 替代 kratos new
go-kratos/blades 是 Kratos 官方维护的增强工具链，但它不是替代品，而是补充。它默认不包含基础项目模板，所有功能（如 blades api、blades biz）都建立在 kratos new 生成的标准结构之上。强行跳过 kratos new 直接用 blades new，大概率触发："template not found: kratos-layout" 错误——因为 blades 默认从 GitHub 拉取模板，而网络策略或权限限制常导致拉取失败；kratos new 则内置了稳定模板缓存，可靠性高一个数量级。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
第一次 kratos run 失败最常见的路径错误
启动命令本身没问题，但失败日志里出现 "failed to load config: open configs/config.yaml: no such file or directory"，90% 是因为你在错误路径下执行了命令。Kratos 的配置加载器默认从当前工作目录读取 configs/，所以必须确保：
立即学习“go语言免费学习笔记（深入）”；
- cd 进入的是项目根目录（即包含
api/、cmd/、configs/的那层），不是cmd/server或internal/biz -
configs/config.yaml文件权限为可读（Linux/macOS 下避免chmod 000误操作） - Windows 用户注意路径分隔符：YAML 中的
data.path: ./data在 Windows 下若写成.\data，会导致os.Open找不到路径
kratos new 后那几分钟里反复确认 protoc 版本、GO111MODULE 状态和当前工作目录——这些细节不显眼，但错一个就全盘阻塞。 
