go mod init 必须指定模块路径，因为它直接决定 import 解析、go get 拉取及依赖管理行为；路径需与托管地址一致（如 github.com/user/repo），否则导致 cannot find module 或伪版本下载错误。
go mod init 为什么必须指定模块路径
模块路径不是随便起的别名，它直接决定 import 语句能否被正确解析、依赖是否能被远程拉取。如果路径和实际代码托管地址不一致（比如写成 myproject 而不是 github.com/username/myproject），其他人在导入你的包时会失败，go get 也找不到源码。
常见错误现象：go: downloading myproject@v0.0.0-00010101000000-000000000000 这种伪版本号，说明 Go 无法识别模块来源；或 cannot find module providing package 报错。
- 模块路径应与 Git 仓库地址对齐（如 GitHub/GitLab URL 的子路径）
- 本地开发阶段可暂用假路径（如
example.com/myapp），但上线前必须改回真实路径 - 路径中不能含大写字母或下划线（Go 模块规范要求小写短横线风格）
go mod tidy 会自动删掉未使用的依赖吗
会，但只删「未被任何 import 引用」的 require 条目。它不会判断你是否在运行时通过反射、插件机制或字符串拼接间接使用某个包——这些情况会被误判为“无用”，导致构建失败。
使用场景：CI 流程中自动清理冗余依赖；团队协作时同步依赖状态；重构后快速验证 import 是否完整。
- 执行前建议先
git status确认没有未提交的代码变更 - 若项目用
plugin.Open()或reflect.ImportPath，需手动在go.mod中加// indirect注释或保留 require -
go mod tidy -v可显示哪些包被添加/删除，便于排查
CGO_ENABLED=0 打包后为什么某些库不可用
因为禁用 CGO 后，所有依赖 C 语言实现的 Go 包都会失效，典型如 net 包（DNS 解析走系统 libc）、os/user、database/sql 的部分驱动（如 mysql 的 cgo 版本）、github.com/mattn/go-sqlite3 等。
性能与兼容性影响：静态链接后体积更小、部署更简单，但牺牲了系统级功能支持；启用 CGO 后生成的二进制文件更大，且需目标机器有对应 libc 版本。
- 替代方案：用纯 Go 实现的库，例如
github.com/go-sql-driver/mysql（纯 Go MySQL 驱动）代替 cgo 版本 - 检查是否含 CGO 依赖：
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' . | xargs go list -f '{{if .CgoFiles}}{{.ImportPath}}{{end}}' - 若必须用 CGO 库，打包时去掉
CGO_ENABLED=0，并确保目标环境安装glibc-devel或musl-dev
embed.FS 和 go:embed 能否打包动态生成的前端资源
不能。嵌入发生在编译期，//go:embed 只接受编译时已存在的文件或目录。如果你的前端资源是 npm run build 产出的，必须保证该步骤在 go build 前完成，否则 embed.FS 读到的是空目录或旧内容。
容易踩的坑：CI 流程里没控制好构建顺序，或者本地开发时忘记重新运行前端构建就直接 go run，结果看到的是上一次的页面。
- 推荐做法：用 Makefile 或 shell 脚本串联
npm install && npm run build && go build - 验证嵌入是否成功：
go tool dist list -json | grep embed不适用，应改用go list -f '{{.EmbedFiles}}' . - 路径匹配注意大小写和斜杠方向，Linux 下
web/dist和web/Dist是两个不同路径
tidy 不懂运行时逻辑，CGO_ENABLED=0 是取舍而非万能开关，embed 不会等你敲完 npm run build 才开始工作。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
