点号导入在 Go 中被编译器禁止，因破坏作用域确定性、使符号来源不可追溯；仅允许在测试文件中导入以 _test 结尾的辅助包；DSL 应通过组合构造、工厂函数或显式解构实现可读性，而非依赖点号导入。
点号导入在 Go 中不被允许，强行使用会导致编译失败，不是风格问题，是语言设计的硬性限制。
为什么 import . "xxx" 会报错
Go 编译器明确禁止点号导入（dot import），因为这会破坏包作用域的确定性：符号来源无法静态追溯，IDE 跳转失效，go vet 和 go lint 会直接拒绝，且 go build 在 1.21+ 版本中已将其列为错误而非警告。
- 典型错误信息：
cannot use . import in non-test code（即使在测试中也仅限于_test.go文件且需谨慎） - 唯一例外是测试文件中导入同名测试辅助包（如
import . "myproj/testutil"），但该包必须以_test结尾且不能导出冲突标识符 - DSL 场景下想“扁平化”API（如让
Rule()直接可用而非dsl.Rule()）时，点号导入是伪解法——它掩盖了命名空间混乱，而非解决表达力问题
DSL 场景下替代点号导入的三种可行做法
真正提升 DSL 可读性的不是省略前缀，而是控制符号暴露粒度和调用链路。Go 的惯用方式是组合 + 函数式构造，而非作用域污染。
- 用
func NewDSL() *DSL返回一个配置对象，把所有 DSL 构建函数挂在其方法上：d := dsl.New(); d.Rule().When(...).Then(...) - 导出一组首字母大写的工厂函数，不加包前缀但靠命名体现领域（如
Match(),Route(),Fail()），放在独立的dsl包里，并在文档中强调“建议显式导入dsl包” - 对极简脚本场景（如 CLI 内置规则引擎），用
func Register(fn interface{})动态注册函数到全局 registry，再通过反射调用——但这牺牲了静态检查，只适用于可信、封闭的 DSL 运行时
常见误用：试图用 init() + 全局变量模拟点号导入
有人在包初始化时把 DSL 函数赋值给全局变量（如 var Rule = dsl.Rule），以为能“透出”到调用方作用域。这是无效的：Go 的作用域是词法作用域，init() 无法突破包边界向外部注入标识符。
立即学习“go语言免费学习笔记（深入）”；
- 现象：调用方仍需写
dsl.Rule()，全局变量只在定义它的包内可见 - 风险：多个 DSL 包做同样事会导致命名冲突（比如两个包都声明
var When func(...)），且无法被go doc正确索引 - 正确思路：如果真要“零前缀”，应在调用方代码里显式解构，例如
import d "myproj/dsl"; rule := d.Rule—— 但不如直接用d.Rule清晰
DSL 的可读性瓶颈从来不在点号上，而在类型提示缺失、错误反馈模糊、组合方式隐晦。与其绕过 Go 的包模型，不如用嵌套结构体、函数选项模式和清晰的返回类型来约束 DSL 的合法路径。这点在 net/http/httptest 或 sqlc 的 Go 模板生成逻辑里已经验证过：好的 DSL 是收敛的，不是放任的。
