本地开发用 invoke-sqlcmd 更顺手，ci/cd 或跨平台部署必须选 sqlcmd；前者依赖 powershell 和 sqlserver 模块，后者轻量跨平台但错误提示弱、参数需转义、go 需原生支持；传参须校验白名单并避免拼接注入；部署失败需分层定位连接、权限或语法问题；create or alter 不能替代依赖检查与显式权限授予。
SQL Server 存储过程部署脚本该用 sqlcmd 还是 Invoke-SqlCmd
直接上结论：本地开发用 Invoke-SqlCmd 更顺手，CI/CD 或跨平台部署必须选 sqlcmd。前者依赖 PowerShell 和 SQL Server 模块，后者是轻量命令行工具，Windows/Linux/macOS 都有原生支持。
常见错误是本地写好 Invoke-SqlCmd 脚本，一丢进 GitHub Actions 就报错 The term 'Invoke-SqlCmd' is not recognized——因为 runner 默认没装 SqlServer 模块，也没开 PowerShell 执行策略。
-
sqlcmd启动快、无额外依赖，适合自动化；但错误提示弱，比如语法错只报Unclosed quotation mark，不指明第几行 -
Invoke-SqlCmd支持变量插值（如-Variable @{"DBName"="MyApp"}），sqlcmd得靠-v参数 +$(var)语法，容易漏转义单引号 - 如果脚本里用了
GO批处理分隔符，sqlcmd原生支持；Invoke-SqlCmd默认不识别GO，得先用正则拆分或加-ErrorAction Stop配合手动批处理
部署脚本里怎么安全传参：数据库名、模式名、环境标识
硬编码 USE [MyDb] 或 CREATE SCHEMA [prod] 是最常踩的坑——一次改错，全环境覆盖。参数必须外部注入，且要校验合法性，不能让任意字符串拼进 SQL。
比如传入 DBName=; DROP DATABASE master--，没过滤就直接拼接，后果不用多说。
- 用
sqlcmd -v DBName="MyApp" SchemaName="dbo"，脚本内写USE [$(DBName)];和CREATE PROCEDURE $(SchemaName).usp_GetUser——注意方括号和点号位置，避免注入 - PowerShell 中用
if ($DBName -notmatch '^[a-zA-Z_][a-zA-Z0-9_]*$') { throw "Invalid DB name" }做白名单校验，比Contains或Replace更可靠 - 环境标识（如
Env=prod）建议只用于条件分支，别直接拼表名；更稳妥的是用配置表或IF @Env = 'prod' BEGIN ... END在存储过程内部控制逻辑
初始化失败后如何快速定位是权限问题还是语法问题
部署卡住时，第一反应不该是重跑脚本，而是看错误是否来自连接层、执行层还是解析层。三类错误特征明显：
- 连接失败：报
Named Pipes Provider, error: 40 - Could not open a connection或Login failed for user→ 检查sqlcmd -S server -U user -P pass -d master -Q "SELECT 1"是否通 - 权限不足：报
The EXECUTE permission was denied on the object 'sp_executesql'或CREATE PROCEDURE permission denied→ 登录用户至少要有db_ddladmin角色，或对目标 schema 有ALTER权限 - 语法/对象依赖错：报
Invalid object name 'Users'或Incorrect syntax near 'CREATE OR ALTER'→ 确认 SQL Server 版本 ≥ 2016（CREATE OR ALTER才可用），且依赖表/函数已存在
建议在脚本开头加 SET NOEXEC ON; GO ... SET NOEXEC OFF; GO 快速做语法预检，不真正执行，省去反复建库删库的时间。
为什么 CREATE OR ALTER PROCEDURE 不能解决所有问题
它确实省去了“先判断再删再建”的麻烦，但掩盖了两个关键现实：依赖关系断裂和权限继承丢失。
比如旧版 usp_GetOrder 有 EXECUTE AS OWNER，新版忘了写，部署后执行权限就没了；又或者过程里调用了 fn_CalcTax()，但这个函数还没部署，CREATE OR ALTER 会成功，运行时才爆错。
- 每次部署前，用
SELECT referencing_schema_name, referencing_entity_name FROM sys.dm_exec_describe_first_result_set(N'EXEC usp_GetOrder', NULL, 0)查实际依赖，比肉眼扫更准 - 权限要显式补：部署完立刻跟一句
GRANT EXECUTE ON OBJECT::[dbo].[usp_GetOrder] TO [app_user];，别指望沿用旧权限 - 如果过程里用了临时表或表变量，
sys.dm_exec_describe_first_result_set可能返回空结果集，这时候得靠单元测试或最小化调用来验证输出结构
真正难的不是写完一个能跑的脚本，而是让同一个脚本，在开发机、测试库、生产主从架构里都保持行为一致——权限、排序规则、兼容级别、甚至 SET 选项（如 ANSI_NULLS）都得对齐，漏一项就可能半夜告警。
