[建议/性能优化] 建议优化 API 模块中的点导入(Dot Import)，降低 Go 编译峰值内存 75%+ 并避免构建卡死

[Garfield247]

🎯 问题背景与现状

目前 ad_open_sdk_go 在 api/ 目录下的所有 API 文件（共 1100+ 个 .go 文件）头部均采用了点导入（Dot Import）：

package api

import (
    . "github.com/oceanengine/ad_open_sdk_go/models" // 点导入
)

导致的问题（Root Cause）

1. 符号表（Symbol Table）急剧膨胀：
   • models 包中定义了全平台所有的请求/响应结构体与枚举常量（数万个符号）。
   • 在 Go 语言中，import . "pkg" 会把该包的所有符号平铺注入到当前文件的包级作用域（Package Scope）。
   • api 包下有上千个文件，导致 Go 编译器在做词法作用域分析与 AST 类型推导时，需要在内存中维护一个数千万条目级别的扁平符号表。
2. 编译峰值内存暴涨与构建卡死：
   • go build 编译峰值内存达到 6GB ~ 8GB+。
   • 在小内存服务器（<16GB）或常见的 CI/CD Docker 构建容器中，极易触发剧烈的 Swap 磁盘 I/O 换页（导致构建耗时从几秒暴增至 5~10 分钟）甚至直接触发 OOM 崩溃。

---

💡 改进建议

1. 移除点导入，改为标准具名导入：

   package api
   
   import (
       "github.com/oceanengine/ad_open_sdk_go/models" // 标准具名导入
   )

2. 为 API 入参与出参中引用的类型显式添加 models. 命名空间前缀：

   // 改进前 (Dot Import)
   func (r ApiOpenApiV30ProjectListGetRequest) Filtering(filtering ProjectListV30Filtering)
   accountType := ACCOUNT_TYPE_ADVERTISER
   
   // 改进后 (Named Models)
   func (r ApiOpenApiV30ProjectListGetRequest) Filtering(filtering models.ProjectListV30Filtering)
   accountType := models.ACCOUNT_TYPE_ADVERTISER

---

📊 实测性能改善对比 (Benchmark)

我们在包含完整 SDK 的项目中进行了编译基准测试，对比结果如下：

指标	优化前 (Dot Imports)	优化后 (Named Models)	改善幅度
编译峰值内存 (Peak Memory)	5 ~ 8 GB	1 ~ 2 GB	↓ 75%
首次编译耗时 (First Build Time)	510 分钟（小内存甚至卡死）	12 分钟	↓ 60%
代码规范性	违反 Go CodeReview 官方规范	符合 Go 最佳实践	-

---

🛠️ 建议落地方式

建议 SDK 维护团队在内部的 OpenAPI / Swagger 代码生成器模板（如 Mustache 模板或 Go template）中，将默认生成的 import . 调整为具名导入 import .../models，从源头彻底解决所有使用 Go 语言的开发者和广告主的构建体验问题。

如果需要参考转换实现或验证脚本，社区已有完整的 AST/正则替换验证方案，非常期待官方的采纳与升级！