go 语言中接口命名遵循清晰、简洁、符合惯例的原则：单方法接口优先使用方法名加 -er 后缀（如 reader、writer），多方法接口则应基于职责选取具描述性的名词（如 io.readwriter、net.conn），避免生硬拼接或滥用 i- 前缀。
go 语言中接口命名遵循清晰、简洁、符合惯例的原则：单方法接口优先使用方法名加 -er 后缀（如 reader、writer），多方法接口则应基于职责选取具描述性的名词（如 io.readwriter、net.conn），避免生硬拼接或滥用 i- 前缀。
在 Go 中，接口命名不是语法约束，而是社区广泛认同的可读性与一致性契约。其核心原则源自 Effective Go 和官方 Code Review 指南：
✅ 单方法接口：优先用 er 形式
这是最经典、最推荐的命名模式，强调接口“能做什么”：
type RoleChecker interface {
IsRole(role Role, hierarchy RolesHierarchy) bool
}
type RoleAssumer interface {
AssumeRole(session ServerSession, role Role)
}
- IsRole → RoleChecker（而非 Roler 或 Roleer）
- AssumeRole → RoleAssumer（自然、无歧义，比 RoleSetter 更贴合语义）
- 即使 Execer 不是标准英语单词，Go 社区也接受——关键是动词 + er 的一致性。
⚠️ 注意：避免强行造词（如 Roler）或过度缩写（如 Rlr），也不推荐 C++ 风格的 IRole 前缀——Go 不强调“接口 vs 实现”的类型标签，而是关注行为契约。
✅ 多方法接口：用职责导向的名词
当接口包含多个相关方法时，应提炼其抽象角色，而非机械拼接：
// 推荐：表达“角色管理能力”的单一职责
type RoleManager interface {
IsRole(role Role, hierarchy RolesHierarchy) bool
AssumeRole(session ServerSession, role Role)
}
// 或更通用的命名（若复用场景广）
type RoleHelper interface {
IsRole(role Role, hierarchy RolesHierarchy) bool
AssumeRole(session ServerSession, role Role)
}
- RoleManager 比 RoleCheckerAssumer 更简洁、更具可读性；
- RoleHelper 在工具型接口中同样合理，前提是它不承担业务核心逻辑（如权限校验主流程），而仅提供辅助能力。
❌ 需规避的命名陷阱
- ServerSessioner：Session 是名词，-er 后缀暗示“执行者”，语义矛盾；正确命名应为 Session（若上下文明确）或 ServerSession（强调服务端会话，已足够清晰）。
-
接收器名 this / self：Go 明确反对。应使用类型缩写，例如：
func (r Role) IsRole(...) bool { ... } // ✅ r 表示 Role func (s *Role) AssumeRole(...) { ... } // ✅ s 表示 *Role（指针接收器）保持同一类型所有方法的接收器名一致（如全用 r），提升代码扫描效率。
? 额外建议：方法签名对齐标准惯例
你的 IsRole 方法签名已合理，但注意：若未来扩展为通用权限检查，可参考 io.Reader 等标准接口的设计哲学——方法名即契约。例如：
- Read() 必须返回 (n int, err error)；
- String() 必须无参数、返回 string。
因此，只要 IsRole 语义稳定（判断角色权限层级），当前签名无需调整；但切勿将 IsRole 重命名为 CheckRole——因 Checker 接口已隐含“检查”动作，方法名保持动词原形更一致。
总之，Go 接口命名的本质是降低认知成本：让读者一眼理解“这个接口能干什么”，而不是“它叫什么”。坚持 -er 惯例、拒绝冗余前缀、精炼多方法接口名称，你的 API 将更符合 Go 的朴素哲学。
