默认开启SSMS中SQLCMD模式是否存在弊端？是否会丢失功能？

我完全懂你为啥要养成开SQLCMD模式的习惯——用:on error exit命令让脚本出错就立刻终止，避免后续数据混乱，之前忘开模式导致花好几分钟清理数据的坑，确实够让人印象深刻的。咱们来拆解你的问题：

可能存在的弊端 #

• 误触发SQLCMD命令：如果你的脚本（哪怕是注释里）出现了类似:r、:setvar这类SQLCMD语法的字符串，SQLCMD模式会把它们当成命令解析。比如你写了-- 注意不要用:r引入其他脚本，这时候SSMS可能会尝试执行:r命令，导致意外报错或行为。不过只要你习惯了这个模式，写脚本时多留意这类字符串，这个问题基本能避免。
• 部分GUI工具兼容性受限：比如使用“显示估计执行计划”或“包括实际执行计划”时，有些复杂的SQLCMD脚本（带变量引用的那种）可能无法正常生成计划，因为执行计划引擎对SQLCMD语法的解析支持有限。但对于普通的查询和部署脚本，这个影响非常小。
• 团队协作的小障碍：如果团队里有不熟悉SQLCMD模式的成员，他们打开你的脚本时可能会看到奇怪的高亮或者报错（比如不认识:on error exit），需要额外解释模式的作用。但如果团队都是做批量部署的，这点小问题根本不算事。

会不会丢失SSMS的功能？ #

大部分核心功能都不受影响：

• 查询编辑器的基础功能——语法高亮、智能提示、代码格式化、调试——都能正常使用（除了刚才提到的部分执行计划场景）。
• 数据库对象的浏览、创建、修改等GUI操作完全不受SQLCMD模式影响，它只作用于查询编辑器的脚本执行环境。
• 唯一可能受限的是一些依赖纯T-SQL解析的高级功能，比如“生成脚本向导”里的某些选项，或者第三方插件对SQLCMD语法的支持不足，但这些都是非常边缘的场景。

20190321更新：我已使用SQLCMD模式约9个月，未遇到任何问题。

这完全在预料之中——如果你的日常工作就是批量部署脚本，而且已经熟悉了SQLCMD模式的语法和注意事项，长期默认开启确实不会有任何问题。很多DBA和部署工程师都会把SQLCMD模式设为默认，就是为了避免你之前踩过的那种坑。

内容的提问来源于stack exchange，提问作者UnhandledExcepSean