go 语言中接口命名遵循清晰、简洁、约定优于配置的原则：单方法接口优先使用方法名加 -er 后缀（如 reader、writer），多方法接口则应基于职责选取具描述性的名词（如 io.readwriter、http.responsewriter），避免生硬拼接（如 “roler”）或冗余前缀（如 “i” 开头）。
go 语言中接口命名遵循清晰、简洁、约定优于配置的原则：单方法接口优先使用方法名加 -er 后缀（如 reader、writer），多方法接口则应基于职责选取具描述性的名词（如 io.readwriter、http.responsewriter），避免生硬拼接（如 “roler”）或冗余前缀（如 “i” 开头）。
在 Go 中，接口命名不是语法要求，而是高度成熟的社区共识，直接影响代码的可读性与可维护性。核心原则源自 Effective Go 和官方 Code Review 指南：
✅ 单方法接口：优先用 er 形式
当接口仅定义一个方法时，标准做法是取该方法名，加上 -er 后缀构成代理名词（agent noun）：
type Reader interface {
Read(p []byte) (n int, err error)
}
type Closer interface {
Close() error
}
type Stringer interface {
String() string
}
即使词形不完全符合英语习惯（如 Execer），也优先保持一致性——这是 Go 的明确约定。
⚠️ 注意：不要为非标准语义的方法套用知名接口名。例如，若你的 IsRole() 行为与 io.Reader.Read 完全无关，就不能命名为 Reader；否则会严重误导使用者。
✅ 多方法接口：用职责导向的名词，而非动词拼接
你的 Role 类型同时提供 IsRole() 和 AssumeRole()，属于典型的多职责抽象。此时不应强行拼凑为 Roler 或 RoleAssumer（语义模糊、不符合英语习惯），而应聚焦其抽象角色：
- ✅ 推荐命名：RoleChecker（若侧重权限校验）、RoleManager（若含状态变更）、RoleContext（若代表运行时角色上下文）
- ✅ 更优解：若两者逻辑强耦合，可统一为 RoleAuthorizer（突出授权语义）或 RoleProvider（强调角色供给能力）
- ❌ 避免：Roler（生造词，无意义）、ServerSessioner（Session 是名词，加 -er 错误暗示“执行 Session 的动作”）、IRole（C++/Java 风格，Go 社区不采用）
示例重构建议：
// 清晰表达“检查角色层级关系”的能力
type RoleChecker interface {
IsRole(role Role, hierarchy RolesHierarchy) bool
}
// 表达“主动切换/承担角色”的能力（注意：AssumeRole 修改状态，通常需指针接收者）
type RoleAssumer interface {
AssumeRole(session ServerSession, role Role)
}
// 若二者必须共存于同一抽象，推荐语义化命名而非机械拼接
type RoleAuthorizer interface {
IsRole(role Role, hierarchy RolesHierarchy) bool
AssumeRole(session ServerSession, role Role)
}
? 其他关键命名规范（配套实践）
-
接收者命名：禁用 this / self。应使用类型缩写，如 r Role、rh RolesHierarchy、s ServerSession，并全程保持一致：
func (r Role) IsRole(role Role, hierarchy RolesHierarchy) bool { ... } func (r *Role) AssumeRole(session ServerSession, role Role) { ... } // 注意指针接收者语义 - 类型名本身：ServerSession 已足够清晰；若项目中无歧义的 ClientSession，直接用 Session 更简洁。
- 常量与字段：ROLE_KEY 建议改为 RoleKey（Go 驼峰惯例），且常量名应体现用途而非存储位置。
? 总结：命名即设计
接口名是 API 的第一张名片。好的名字能减少文档依赖、降低理解成本、预防误用。牢记三句话：
? 单方法 →
? 多方法 →
? 拒绝翻译腔、拒绝前缀（I, ISomething）、拒绝动词化名词（Sessioner）
最终选择 RoleChecker 还是 RoleAuthorizer，取决于你希望暴露的是「校验能力」还是「完整的角色管理契约」——这本质上是一个设计决策，而 Go 的命名规范，正是帮你做出清晰决策的标尺。
