Go语言internal与pkg同名包的结构设计及导入问题咨询

首先明确：语法上你可以这么做，但实际开发中强烈不推荐。

为什么语法上可行？ #

Go 的包导入是基于完整路径而非包名区分的，所以你确实能通过app/my-app/internal/accounts和app/my-app/pkg/accounts分别导入这两个同名包，还能通过别名区分使用：

import (
    internalAcc "app/my-app/internal/accounts"
    pkgAcc "app/my-app/pkg/accounts"
)

func main() {
    internalAcc.DoInternalThing()
    pkgAcc.ExposeToExternal()
}

为什么不推荐？ #

这种结构会让代码可读性和维护性大幅下降：

• 团队成员很容易搞混两个包的职责，比如不小心把内部逻辑误用到对外接口中
• 同名包在代码跳转、全局搜索时容易出现歧义，增加调试和协作成本

更合理的实践方案 #

既然accounts既有内部实现又有对外接口，建议用「内部包存核心逻辑，外部包做封装暴露」的结构，完全不需要同名包：

目录结构示例：

my-app
  - pkg
    - accounts
      - api.go  // 仅定义对外暴露的函数、接口，封装内部实现
  - internal
    - accounts
      - service.go  // 存放核心业务逻辑，仅内部模块可访问

代码示例：

// internal/accounts/service.go
package accounts

// 内部实现函数，仅内部模块可调用
func CreateUserInternal(username string) error {
    // 核心业务逻辑
    return nil
}

// pkg/accounts/api.go
package accounts

import "app/my-app/internal/accounts"

// 对外暴露的函数，封装内部实现
func CreateUser(username string) error {
    return accounts.CreateUserInternal(username)
}

这种结构职责清晰：外部依赖只能导入pkg/accounts使用对外接口，内部模块可以直接调用internal/accounts的核心逻辑，既避免了同名包的混淆问题，也完全符合Go的internal目录设计初衷。

内容的提问来源于stack exchange，提问作者Lorenzo Piccoli Módolo