当将子域名逻辑拆分为独立 Go 项目并尝试复用主项目的 mux.Router 实例时，因重复 vendoring 导致类型不兼容——根本原因是两个项目各自维护了独立的 vendor/github.com/gorilla/mux 副本，Go 将其视为不同包类型。

当将子域名逻辑拆分为独立 go 项目并尝试复用主项目的 `mux.router` 实例时，因重复 vendoring 导致类型不兼容——根本原因是两个项目各自维护了独立的 `vendor/github.com/gorilla/mux` 副本，go 将其视为不同包类型。

在 Go 的模块依赖模型中（尤其在启用 GO111MODULE=on 且使用 vendor/ 目录时），包路径的完全一致性决定了类型的可互换性。即使两个 vendor 目录下 github.com/gorilla/mux 的代码内容完全相同，只要它们位于不同路径（如 primary_site/vendor/github.com/gorilla/mux 和 subdomain_site/vendor/github.com/gorilla/mux），Go 编译器就会将 *mux.Router 视为两种不兼容的类型——这正是你遇到的编译错误：

# command-line-arguments ./main.go:25:
cannot use r (type *"primary_site/vendor/github.com/gorilla/mux".Router)
as type *"subdomain_site/vendor/github.com/gorilla/mux".Router
in argument to routers.LoadRoutes

✅ 正确解决方案：统一 vendor 目录

Go 并不支持跨 vendor 目录共享 vendored 类型。因此，必须消除重复 vendor，只保留一个权威的、顶层的 vendor/ 目录：

1. 删除子项目中的 vendor/ 目录

   rm -rf subdomain_site/vendor

2. 确保主项目（primary_site）已正确 vendor 所有依赖（包括 gorilla/mux）

   cd primary_site
   go mod vendor  # 或使用 dep ensure 等工具，取决于你使用的依赖管理方式

3. 在子项目中通过相对路径或模块路径引用主项目的代码，并确保其构建时能访问主项目的 vendor/
   推荐方式是：将子项目作为主项目的子模块（或本地模块）管理，例如在 primary_site/go.mod 中添加：

   replace github.com/yourorg/subdomain => ./subdomain_site

   同时确保 subdomain_site/go.mod 中声明正确的模块名（如 module github.com/yourorg/subdomain），且不包含 vendor/。

4. 构建时始终从主项目根目录执行 go build 或 go run
   这样 Go 工具链会自动识别并使用 primary_site/vendor/ 下的依赖，子项目中的 import "github.com/gorilla/mux" 将解析为同一物理包，类型自然兼容。

⚠️ 注意事项

• ❌ 不要手动复制 gorilla/mux 到子项目 vendor —— 这只会加剧冲突。
• ✅ 若使用 Go Modules（推荐），可完全弃用 vendor/，改用 go mod tidy && go build；此时只要所有项目共用同一 go.mod 依赖版本（或通过 replace 统一），类型即天然一致。
• ? 验证是否成功：在子项目代码中打印 fmt.Printf("%s\n", reflect.TypeOf(r).PkgPath())，应显示完全相同的包路径（如 github.com/gorilla/mux），而非带 vendor 路径的变体。

总结

类型冲突的本质不是 Gorilla Mux 本身的问题，而是 Go 的包唯一性机制在多 vendor 场景下的必然表现。“一个项目，一个 vendor 目录” 是跨包共享 vendored 类型的硬性前提。 拆分子服务时，优先采用 Go Modules + replace 或 require 管理依赖；若必须 vendor，则务必扁平化至单一顶层目录——这是保障接口契约（如 *mux.Router）在项目间无缝传递的基石。