SQL Server容器启动时SA_PASSWORD必须加密传递，禁用明文环境变量；应使用--env-file、Kubernetes Secret或Docker Swarm secret注入，并校验变量非空，避免日志泄露密码。
SQL Server容器启动时，SA_PASSWORD必须加密传递，不能明文写在命令行里
直接用 docker run -e SA_PASSWORD=MyPass123! ... 启动容器，密码会出现在 ps aux 输出和容器元数据中，任何有宿主机权限的人都能轻易获取。这不是“可能泄露”，而是“必然可见”。
- 正确做法：改用
--env-file，把SA_PASSWORD单独写进一个只读文件（如sql-secrets.env），该文件不纳入 Git，且权限设为600 - 更稳妥的路径：在 Kubernetes 中用
Secret挂载；在 Docker Swarm 中用docker secret create注入 - 注意：
ACCEPT_EULA=Y可以明文传，但所有含凭证的变量都必须隔离
DATABASE_URL 构造时别拼接明文密码，优先用连接字符串参数化方式
很多应用代码里写 export DATABASE_URL="postgresql://user:$PASSWORD@host:5432/db"，一旦日志级别设为 debug 或异常堆栈打印完整 URL，密码就裸奔了。
- 推荐拆解：只传
DB_HOST、DB_PORT、DB_NAME、DB_USER，密码通过独立变量DB_PASSWORD传入，由应用层组装连接串（并确保不记录该变量值） - 若必须用完整 URL，至少确保应用框架支持从环境变量中剥离敏感段（如 Django 的
django-environ支持urlparse解析并过滤密码） - 验证点：检查应用日志配置是否禁用了
env变量 dump 功能（比如某些 ORM 的echo=True会打印带密码的 SQL URL）
Docker Compose 中混用 env_file 和 secrets 是当前最实用的安全分层方案
单纯靠 .env 文件管理所有变量，等于把钥匙挂在门把手上——它不加密、不鉴权、不审计。
-
env_file适合存非敏感项：如LOG_LEVEL、DEBUG=False、TIMEZONE=Asia/Shanghai -
secrets必须用于高敏字段：如SECRET_KEY、SA_PASSWORD、JWT_PRIVATE_KEY，Docker 会在运行时以文件形式挂载到容器内指定路径（如/run/secrets/secret_key），应用需主动读取 - 关键细节：Docker Compose 的
secrets不支持 Windows 宿主机，本地开发若用 WSL2 则无问题；生产环境建议统一走 Kubernetes Secret
容器内进程启动前，必须校验关键环境变量是否存在且非空
漏掉 SA_PASSWORD 或 SECRET_KEY 导致服务静默失败，比报错更危险——它可能用默认密钥或空密码继续运行。
- 在入口脚本（如
entrypoint.sh）开头加校验逻辑：if [ -z "$SA_PASSWORD" ]; then echo "FATAL: SA_PASSWORD not set" >&2; exit 1; fi - 避免用
||简单兜底（如${SA_PASSWORD:-fallback}），这会让空值被当作有效值使用 - Yearning、Dify 等开源项目已内置类似检查，但自研服务务必自己加——没人会替你守这个底线
secrets，而是每次部署时都记得删掉测试用的 .env 临时副本、每次 CI 流水线都确认没把 SA_PASSWORD 打印进日志、每次新同事接手都重新核对权限模型。安全配置不是一次设置，而是持续咬住的细节。 
