SQL Server存储过程读取环境配置的正确方法是通过参数传入或查询预设的ConfigSettings表，而非使用危险的xp_cmdshell或不可靠的服务器名判断；MySQL应强制显式传参并校验；PostgreSQL需由连接层SET后再用current_setting()读取；跨库统一做法是所有逻辑接受p_env参数，由外层适配器按数据库类型获取环境值。
SQL Server 存储过程中怎么读取环境配置变量
SQL Server 本身不支持运行时环境变量（如 Linux 的 $ENV_VAR 或 .NET 的 Environment.GetEnvironmentVariable），直接在 T-SQL 里调用会报错 Invalid object name 'sys.dm_exec_sessions' 或更常见的 Could not find stored procedure 'xp_cmdshell' —— 别急着开 xp_cmdshell，它既危险又常被禁用。
真正可行的路只有一条：把环境标识（如 'dev'、'prod'）作为参数传进来，或从一个预设的配置表里查。硬编码或靠服务器名判断（@@SERVERNAME）看似省事，但一到容器化部署或蓝绿发布就崩。
- 推荐做法：建一张
ConfigSettings表，含字段Key NVARCHAR(50)、Value NVARCHAR(200)、Environment NVARCHAR(20) - 查询时加 WHERE 条件，比如
SELECT Value FROM ConfigSettings WHERE Key = 'ApiBaseUrl' AND Environment = @Env - 避免用
SERVERPROPERTY('MachineName')做判断——测试环境和生产环境可能同机部署，名字一样但行为要不同
MySQL 存储过程里如何安全注入环境上下文
MySQL 8.0+ 支持用户变量和系统变量，但 @env 这类会话变量不能跨存储过程传递，且容易被后续语句覆盖。最稳的方式是：让调用方显式传参，而不是让存储过程自己猜。
常见错误是写成 SET @env = IFNULL(@env, 'dev'); —— 看似兜底，实则埋雷：如果上层没初始化 @env，这个变量就是 NULL，IFNULL 也救不回来，整个逻辑走默认分支，上线后才发现连错了数据库。
- 强制要求入口参数，例如
CREATE PROCEDURE usp_do_something(IN p_env VARCHAR(10)) - 开头立刻校验：
IF p_env NOT IN ('dev', 'staging', 'prod') THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid environment'; END IF; - 别依赖
@@hostname或@@port推断环境——Docker 容器里它们往往都是localhost或随机值
PostgreSQL 函数中怎么隔离 dev/prod 配置路径
PostgreSQL 的 current_setting() 可以读自定义配置，但必须先用 SET 设置，而 SET 是会话级的，没法在函数里自动生效。直接调用 current_setting('app.env') 报错 unrecognized configuration parameter 是常态。
根本解法不是“怎么读”，而是“谁来设”。应用连接池（如 PgBouncer、pgpool）或 ORM 层应在建连后立刻执行 SET app.env = 'prod'；函数内部只负责使用，不负责探测。
- 建自定义配置项：在
postgresql.conf加app.env = 'dev'，或用ALTER SYSTEM SET app.env = 'dev'（需 reload） - 函数内用
current_setting('app.env', true)，第二个参数true表示失败时不抛异常，返回 NULL —— 这比默认行为更可控 - 避免在函数里写
SHOW app.env：它返回的是记录集，不能直接赋值给变量，语法不匹配
跨数据库迁移时环境变量逻辑怎么保持一致
当同一套业务逻辑要跑在 SQL Server + PostgreSQL 上，硬写三套判断逻辑（IF @@SERVERNAME LIKE '%prod%' / CURRENT_SETTING('app.env') / SELECT @@hostname）只会让维护成本翻倍。统一抽象层不是可选项，是止损线。
最轻量的做法：所有存储过程/函数都接受 p_env 参数，并在最外层包装一层“环境适配器”——比如一个叫 usp_wrapper 的 SP，它根据当前实例类型查出环境名，再调用真实逻辑。这样核心逻辑不感知数据库差异，变的只是壳。
- SQL Server 侧：适配器从
sys.configurations或专用配置表读app.environment - PostgreSQL 侧：适配器调用
current_setting('app.env', true)，为空时 fallback 到current_database()名称规则（如%_prod） - 禁止在应用代码里拼接 SQL 字符串来“动态切换环境”——这等于放弃参数化，SQL 注入风险陡增
环境配置不是越自动越好，而是越明确、越不可绕过越好。一旦允许“默认值兜底”，就等于默许某次部署漏配环境变量，而这种问题总在凌晨三点爆发。
