ConfigMap挂载到Go应用的两种主流方式是环境变量注入和文件挂载：前者通过env + configMapKeyRef将键值注入为环境变量，Go用os.Getenv()读取；后者通过volumes与volumeMounts挂载为文件，Go需解析配置文件内容。
ConfigMap挂载到Go应用的两种主流方式
ConfigMap不是自动生效的，必须显式挂载进Pod才能被Go程序读取。最常用的是环境变量注入和文件挂载，选哪种取决于你的Go应用解析配置的方式。
环境变量适合简单键值对（比如 DB_HOST、LOG_LEVEL），Go里直接用 os.Getenv() 就能拿到；文件挂载适合结构化配置（如 config.yaml 或 .env），Go需用 ioutil.ReadFile() 或第三方库解析。
- 环境变量方式：在Deployment中用
env+configMapKeyRef，每个键单独声明 - 文件挂载方式：用
volumes定义ConfigMap，再用volumeMounts挂到容器路径，注意subPath控制单个键映射 - 文件挂载时若ConfigMap更新，容器内文件默认不会热更新（Kubernetes v1.28+ 支持
immutable: true但不解决热更）
用client-go在Go代码里动态读取ConfigMap
如果你的Go服务需要运行时感知ConfigMap变更（比如配置热重载），就不能只靠启动时注入，得用client-go主动拉取——但这不是零成本操作，容易踩坑。
- 必须初始化
*rest.Config：Pod内用rest.InClusterConfig()，本地调试换clientcmd.BuildConfigFromFlags("", kubeconfigPath) -
namespace参数不能为空字符串，否则报错namespaces "" not found -
CoreV1().ConfigMaps(namespace).Get()第二个参数必须是metav1.GetOptions{}，传nil在 client-go v0.28+ 会 panic - 频繁轮询会增加API Server压力，建议加缓存或用
Watch()监听事件，但 Watch 需处理连接断开与重试
ConfigMap内容编码与Go读取的兼容性问题
ConfigMap的 data 字段是纯文本，但YAML解析器对换行、缩进、特殊字符很敏感，Go读取时容易出错。
- 避免在YAML里写裸JSON或嵌套YAML：比如
database_config: "{host: db, port: 5432}"，Go反序列化易失败；应拆成独立key：db_host、db_port - 含换行的内容（如TLS证书）必须用
|或|-块符号，否则会被压缩成一行，导致Go解析PEM失败 - 挂载为文件时，确认Go应用打开路径权限正确（如
/etc/config/app.yaml），且路径在volumeMounts.mountPath下真实存在 - 用
kubectl get configmap NAME -o yaml检查实际存储内容，别只信编辑器里的YAML格式
ConfigMap与Secret混用时的常见误配
ConfigMap和Secret经常一起用（比如ConfigMap放 DB_HOST，Secret放 DB_PASSWORD），但它们的引用语法不同，写错会导致环境变量为空。
- ConfigMap引用写法：
configMapKeyRef: {name: my-config, key: db_host} - Secret引用写法：
secretKeyRef: {name: my-secret, key: password}—— 不是configMapKeyRef - 两者不能混用字段名，比如用
secretKeyRef去读ConfigMap，结果是空，且无错误日志 - Go代码里统一用
os.Getenv("DB_HOST")读，不区分来源，所以配置项命名要全局唯一，避免Secret覆盖ConfigMap同名key
