Buffalo项目不能直接按Go module拆分，因其本质是单一Go module，所有目录属同一模块；跨模块import会导致路由丢失或panic，解耦应通过package划分与显式注册实现。
Buffalo 项目能直接按 Go module 拆分吗
不能。Buffalo 项目本质是一个单一 Go module，go.mod 声明的是整个项目根路径，所有 actions/、models/、grifts/ 目录都属于同一模块下的包。你无法像微服务那样把 users 和 orders 分成独立可 go get 的子模块——buffalo dev 启动时会扫描全部 actions/*.go 文件做反射注册，跨模块 import 会导致路由丢失或 panic。
想隔离逻辑，该用 package 还是 directory
用目录 + 显式包名，不是靠文件夹物理隔离。Buffalo 不识别“模块目录”，只认 Go 包导入路径和 app.Routes() 中的 handler 注册位置。
- 在
actions/下建actions/users/和actions/orders/子目录，但每个目录内必须声明package users或package orders - handler 函数仍要被
app.GET("/users", users.List)这类显式调用注册，不能指望 Buffalo 自动发现子目录 - 避免在
actions/users/里 import"myapp/actions/orders"—— 这会造成循环依赖，因为actions/整体被main.go作为主包引用 - 真正解耦的方式是把共享逻辑（如验证、工具函数）抽到
lib/或pkg/目录，并用go mod edit -replace本地覆盖调试
models 层怎么安全拆分
models/ 是 Buffalo 中最常误拆的部分。pop ORM 的 Connection 是全局单例，所有 model 都共享同一个 DB 实例，强行分包会导致 migration 冲突或事务失效。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 保持
models/models.go为唯一 DB 初始化入口，不要在models/users/user.go里重复调用pop.NewConnection - 每个 model 结构体可以放在独立文件（如
models/user.go、models/order.go），但都属models包，且必须在models/models.go的init()或NewDB()中显式注册：db.AddModel(&User{})、db.AddModel(&Order{}) - 迁移文件仍统一放在
./migrations/，不要按 domain 分散——soda CLI 只读这个路径，分散后buffalo db migrate会漏执行 - 若需不同数据库（如用户走 PostgreSQL、日志走 SQLite），必须手动新建
pop.Connection实例并绕过 Buffalo 默认模型加载机制，此时已脱离标准流程
拆分后 buffalo dev 还能热重载吗
能，但仅限于被 actions/ 直接 import 的包。Buffalo 的文件监视器只监听 actions/、models/、grifts/ 和 templates/ 四个硬编码路径，改 pkg/utils.go 不会触发重建。
- 开发阶段，把高频修改的逻辑（如 API 封装、校验规则）放
actions/或models/下，避免切到外部包调试卡顿 - 如果坚持用
pkg/，需配合air或fresh替代buffalo dev：写.air.toml加入root_dir = "."和include_dirs = ["pkg"] - 注意
buffalo build默认不打包pkg/外部目录，若二进制依赖它，得手动加--ldflags="-X main.pkgPath=..."注入路径
真正的模块边界不在目录结构，而在 app.Routes() 的注册粒度和 models.NewDB() 的连接管理方式。任何试图模仿 Java Spring Boot 的 package-by-feature 拆法，都会撞上 Buffalo 的反射注册与单体构建模型——它设计之初就没打算支持运行时插拔模块。
