实战经验：Gone 框架模块化改造中的 go work 反思
🚀 发现 gone-io/gone：一个优雅的 Go 依赖注入框架！💻 它让您的代码更简洁、更易测试。🔍 框架轻量却功能强大，完美平衡了灵活性与易用性。⭐ 如果您喜欢这个项目，请给我们点个星！🌟 您的支持是我们前进的动力！🤝 欢迎贡献代码或提出建议，一起让 gone 变得更好！👨💻 #golang #依赖注入 #开源 👉github.com/gone-io/gone
本文原地址：https://github.com/gone-io/goner/blob/main/docs/try-go-work.md
文章目录
-
- 背景介绍
- go work 的基本使用场景
- go work 存在的问题
-
- 1. 命令兼容性问题：最致命的局限
- 2. 版本管理混乱
- 3. CI/CD 集成问题
- 实际案例：gone 框架的模块化挑战
- 结论：有用，但很鸡肋
随着项目的不断扩大，代码库的膨胀，模块化开发变得越来越重要。在 Go 语言生态中，官方提供了
go work 命令来支持多模块开发。但在实际使用过程中，我发现这个工具并不像预期那样好用。本文将分享我在 gone 框架模块化改造过程中对
go work 的调研和使用体验。
背景介绍
最近我正在进行 gone 框架的模块化改造（Gone框架模块化改造之路）。随着功能的不断增加，gone 框架变得越来越复杂，为了更好地维护代码和允许用户按需使用功能，我决定将框架拆分为