企业官网建设流程全解析

1. 问题现场还原：SQL Prompt 9.0为什么突然"罢工"

先说说我遇到的具体情况。之前一直用得好好的SQL Prompt 9.0，某天早上打开SSMS准备写存储过程，突然发现智能提示全部消失了，代码一片黑白，跟记事本一样。打开菜单栏，SQL Prompt的菜单项还在，但点击之后要么没反应，要么弹出一个报错窗口提示"License validation failed"或者说"找不到许可证"。更离谱的是，有时候重启SSMS能恢复，但用不到十分钟又失效。

这个场景我相信很多用过SQL Prompt的人都经历过。SQL Prompt是Redgate公司出的一款SQL Server智能提示插件，确切的版本号是9.0.xxxxx，它跟Visual Studio、SSMS深度集成，提供代码补全、格式化、重构这些能力。它的许可证验证机制比较复杂，同时存在"本地许可证文件校验"和"后台联网校验"两条验证路径。一旦某条路径出了问题，插件的功能就会被锁死，表现就是菜单还在、功能全无。

我先给结论：绝大多数SQL Prompt 9.0"突然不能用"的情况，不是插件损坏，而是许可证校验机制被触发了。触发的原因主要有三类：一是许可证文件因为异常退出被标记为无效；二是插件后台联网校验时连不上Redgate的服务器，超时后自动进入降级模式；三是SSMS升级或.NET Framework更新导致插件加载失败。搞清楚这个前提，后面的修复思路就清晰了，不用一上来就卸载重装。

2. 恢复核心功能：让SQL Prompt 9.0先跑起来

2.1 快速检测插件加载状态

第一步要判断到底是插件没加载，还是加载了但功能被禁用。打开SSMS，点击菜单栏的"工具" → "扩展"，在已安装列表里找SQL Prompt。如果这个列表里压根看不到SQL Prompt，说明扩展没有被加载，需要去检查安装目录和注册表加载项；如果列表里有，但旁边显示"已禁用"，右键选择"启用"即可。实测下来，很多人的问题就卡在这一步，插件被SSMS自动禁用了却浑然不知。

2.2 清理并重建许可证状态

如果扩展处于已加载状态但功能不可用，那基本可以确定是许可证校验出了问题。SQL Prompt 9.0的许可证信息存储在%ProgramData%\Red Gate\SQL Prompt 9目录下，其中核心文件是LicenseKeys.xml。在动手之前建议先备份这个目录到别的盘，然后执行以下操作：

1. 关闭所有SSMS和Visual Studio实例。
2. 打开Windows服务管理器，找到"Red Gate Background Service"服务，右键停止。
3. 打开%ProgramData%\Red Gate目录，找到SQL Prompt 9文件夹，把里面的LicenseKeys.xml重命名为LicenseKeys.xml.bak。
4. 重新启动"Red Gate Background Service"服务。
5. 打开SSMS，此时SQL Prompt 9会提示输入许可证密钥。如果你用的是正式购买的序列号，重新输入即可；如果是试用版，则需要重新获取试用许可。

注意：%ProgramData%默认是隐藏目录，建议在资源管理器地址栏直接输入路径回车，比去"查看→隐藏的项目"里找要快得多。

完成之后重启SSMS，绝大多数情况下智能提示就回来了。这个方案的核心逻辑是让插件在下次启动时重新走一遍许可证验证流程，把原来那个"半损坏"的本地许可证状态覆盖掉。

2.3 注册表残留清理法

还有一种情况，许可证文件看起来正常，但插件就是在启动时报错。这往往是SQL Prompt 9.0的注册表项损坏导致的。SQL Prompt 9.0的注册表项位于HKEY_CURRENT_USER\Software\RedGate\SQL Prompt 9。操作前务必先导出备份这个注册表分支，然后删除该分支下的Licenses子项，重启SSMS让插件重新生成。

这个方法我印象很深，有一次帮同事处理一个SQL Prompt 9.0无法使用的问题，试了清理许可证文件、修复安装都没用，最后删了注册表Licenses子项反而好了。原因是他的系统时间之前被改过，导致许可证的本地缓存时间戳跟实际时间产生了不可调和的偏差，删掉注册表项后插件会以当前系统时间为基准重新校验，问题瞬间解决。

2.4 彻底卸载并重新安装

如果前面三种方式都没能恢复，那就只能走卸载重装这条路了。这里要特别提醒一句：不要直接从"控制面板→程序和功能"里卸载了事，那个方式会残留很多文件和注册表项，导致重装后问题依旧。建议用Redgate官方的卸载方式：关闭所有IDE，打开控制面板卸载SQL Prompt 9，然后手动检查这几个目录是否清理干净：

• %ProgramData%\Red Gate\SQL Prompt 9
• %LocalAppData%\RedGate\SQL Prompt 9
• %AppData%\RedGate\SQL Prompt 9

重装时直接运行安装包，选择Repair（修复）模式。我自己的经验是，如果修复模式能解决问题，就尽量不要走完整卸载，因为完整卸载和重装有概率丢失SSMS的主题配色方案和部分快捷键设置，修复模式则会保留个人配置。

3. 防联网激活的完整设置思路

3.1 为什么要做联网控制

SQL Prompt 9.0在启动时会向Redgate的许可证服务器发起HTTPS请求，确认当前许可证是否有效。如果程序检测到许可证处于"待激活"状态，会弹窗提示激活；如果检测到已在别的机器上激活过，会直接锁定当前机器的使用权限。对于使用正版但网络环境不稳定的用户，或者是企业内部网络受限的用户，联网校验失败会频繁导致许可证验证卡顿、功能降级。这时候做"防联网激活"，本质上就是通过防火墙规则阻止SQL Prompt相关进程发起外联请求，让插件只能走本地许可证校验，从而稳定运行。

3.2 针对SQL Prompt 9.0的防火墙出站规则配置

Windows Defender防火墙是大多数Windows机器的标配，配置出站规则来拦截SQL Prompt的联网请求是目前最快的路径。具体操作：

1. 打开"控制面板" → "Windows Defender防火墙" → 左侧选择"高级设置"。
2. 在左侧树形菜单中选中"出站规则"，右侧点击"新建规则"。
3. 规则类型选择"程序"，点击"下一步"。
4. 选择"此程序路径"，点击"浏览"，找到SQL Prompt的安装目录。SQL Prompt 9.0默认安装在C:\Program Files (x86)\Red Gate\SQL Prompt 9，核心进程是SQLPrompt.exe和RedGate.ClientService.exe。
5. 选择"阻止连接"，下一步。
6. 三个配置文件（域、专用、公用）都勾选，继续。
7. 名称填SQLPrompt Block Internet，点击"完成"。

注意：SQL Prompt 9.0的联网验证不只有主进程，它还有一个后台服务"Red Gate Background Service"，对应的可执行文件通常在C:\Program Files (x86)\Red Gate\Shared\RedGate.SharedSQLTools.BackgroundService.exe。只拦主程序不拦后台服务，等于白拦。最好是两条规则都建上。

我实测拦截这两个进程之后，SQL Prompt 9.0启动速度反而变快了，因为省掉了向Redgate服务器发起HTTPS握手和等待响应的几百毫秒。同时，许可证状态稳定在"本地有效"，不会因为网络波动出现"找不回许可证"的尴尬情况。

3.3 hosts文件屏蔽方式的对比

除了防火墙规则，还有一部分人会选择在hosts文件里添加127.0.0.1的映射来屏蔽Redgate的服务器域名。这个方案对老版本有效，但SQL Prompt 9.0的域名解析有时走的是CDN，IP不固定，加上程序内部可能配置了备用域名，单纯改hosts不一定能堵得死。相比之下，防火墙出站规则是按程序路径匹配的，只要进程还在，流量就会被拦，安全性更可控。

不过有一个例外：如果SQL Prompt 9.0的联网验证域名正好是固定的几个，而且你不想在防火墙里动太多手脚，可以优先用hosts方案。具体做法是：记事本以管理员身份打开C:\Windows\System32\drivers\etc\hosts，在末尾添加以下内容：

127.0.0.1 redgate.com 127.0.0.1 www.redgate.com 127.0.0.1 licensing.redgate.com

保存后执行ipconfig /flushdns刷新DNS缓存。这个方法我提一句，但并不作为首选推荐，因为你无法穷举Redgate所有可能用到的域名，漏一个就等于白做，防火墙还是更靠谱。

3.4 验证防联网是否生效

配置完防火墙规则后，需要验证一下到底有没有生效。最简单的方法是查看SQL Prompt的日志文件。SQL Prompt 9.0的日志路径在%LocalAppData%\RedGate\SQL Prompt 9\Logs，打开最新的日志文件，搜索"license"或"activation"关键字。如果日志里出现了Offline license check succeeded或者Using cached license这类字样，说明本地校验已经生效，不会再尝试联网。如果日志里还在频繁出现Connecting to licensing server...，说明还有漏网进程，需要回头检查防火墙规则是否覆盖了所有相关进程。

另外，可以在配置完出站规则后，打开任务管理器，找到SQL Prompt相关进程，右键"打开文件所在位置"，确认进程路径和防火墙规则里填的路径一致。路径不一致是防火墙规则失效的最常见原因。

4. 常见问题与排查技巧实录

4.1 SQL Prompt菜单灰色不可点击

菜单项还在但全是灰色，这种情况在SQL Prompt 9.0里特别常见，通常意味着插件的许可证状态处于"评估已过期"或"许可证未激活"。优先检查设置路径：SSMS菜单栏"SQL Prompt" → "License" → "Enter License Key"。如果这个入口是灰色的，则直接杀掉SSMS进程，重新以管理员身份打开SSMS再试。

实操心得：SSMS一定要用管理员身份运行，否则有的机器上SQL Prompt的许可证写入权限不足，导致每次启动都无法写入有效的许可证状态。这个坑我踩过好多次，后来养成了习惯，开发用SSMS一律右键管理员身份运行。

4.2 安装了SQL Prompt 9.0但SSMS菜单栏完全没出现

并排除了许可证问题，大概率是SSMS版本不兼容导致扩展没有被加载。SQL Prompt 9.0发布时官方支持SSMS 2014到2017，但很多人后来升级到了SSMS 18或更新的版本。解决方案有两种：一是去官网下载SQL Prompt 10或11的新版本，旧版本9.0已经停止更新，对新时代的SSMS兼容性确实不佳；二是如果你必须用9.0，可以尝试将SSMS回退回2017版本，但不建议为了一个插件放弃新版本SSMS的性能和功能提升。

4.3 修复后有补全但格式化功能无法使用

这个情况比较隐蔽。SQL Prompt 9.0的代码格式化功能依赖一组预设的风格配置文件，存放于%AppData%\RedGate\SQL Prompt 9\Formatting目录下。如果之前你做过自定义格式化配置，但配置文件的编码或者内容损坏，格式化功能就会处于"半瘫痪"状态。解决方法是把Formatting目录下的所有.xml文件先移动到其他位置备份，然后重启SSMS，让SQL Prompt重新生成默认格式化配置。之后再一个个恢复你的自定义配置，定位是哪个文件损坏了。

4.4 后台服务占用CPU过高

配置好防火墙规则后，有的机器会出现"Red Gate Background Service"进程CPU占用飙高的现象。这个不是防火墙规则导致的，而是因为SQL Prompt被阻止联网后，它每隔一段时间会尝试重新连接服务器，连接失败后进入重试循环。可以通过Windows"服务"管理器中，找到"Red Gate Background Service"，将启动类型改为"手动"，然后手动停止该服务。实测下来，SQL Prompt 9.0的核心补全功能不依赖这个后台服务，停掉它影响不大。

4.5 虚拟机或远程桌面环境下SQL Prompt行为怪异

如果是通过远程桌面连接到开发机使用SQL Prompt，并且发现输入代码时提示框弹出位置错乱或者闪烁，这是SQL Prompt 9.0旧版本在远程桌面会话中的已知渲染问题。处理方法有两个：一是在SSMS选项中打开"SQL Prompt" → "Suggestions" → "Enable transparent hint window"并取消勾选；二是直接升级到SQL Prompt 10或11，新版本对远程桌面和GPU渲染做了优化，体验提升明显。

4.6 排查问题的高效顺序

每次遇到SQL Prompt 9.0无法使用，我建议按照下面这个顺序排查，别一上来就重装：

1. 检查"工具→扩展"，确认插件是否加载、是否被禁用。
2. 查看SQL Prompt日志目录的日志文件，确认报错关键字。
3. 验证防火墙规则是否覆盖了所有相关进程。
4. 清理LicenseKeys.xml并重新激活。
5. 修复或重装SQL Prompt 9。

这套顺序看起来简单，但能解决掉90%以上"突然无法使用"的案例。很多人一遇到问题就怀疑插件坏了，火急火燎去卸载重装，结果装回来配置全丢，问题还没解决。冷静下来按顺序排查，既省时间又不会丢失自己的使用习惯配置。

5. SQL Prompt 9.0使用与维护的几点经验总结

用SQL Prompt 9.0这几年下来，我觉得有几点经验值得跟大家分享：

第一，永远不要用破解版或注册机。市面上流传的所谓"永久激活版"SQL Prompt 9.0，往往会被植入挖矿程序或后门，你的数据库连接信息、账号密码分分钟被窃取。做开发工作，工具的钱不能省，Redgate的许可价格对于团队来说属于低成本投入，完全可以直接购买正版。

第二，做好配置备份。SQL Prompt的配置非常个人化，格式化风格、代码片段、快捷键绑定都值得仔细打磨。建议定期把%AppData%\RedGate\SQL Prompt 9这个目录打包存到一个私人仓库里，换机器或者重装系统后直接恢复，几秒钟就能把整个开发环境拉回原来的状态。

第三，搞清楚"防联网激活"和"盗版绕过"的边界。前者的正当使用场景是：你已经购买了合法许可证，但因为网络限制或服务器波动导致授权验证不稳定，通过防火墙规则保证软件稳定性；后者则是破解付费软件。为了省几百块钱去走灰色路径，一旦泄露公司数据库连接串，后果远比那点授权费严重。

第四，版本升级要谨慎但不抵触。我本人也经历了从9.0到11的升级，说实话新版本在性能、远程桌面兼容性、对Azure SQL Database的支持上都比9.0强不少。如果团队里还在用着9.0，建议在测试环境里跑一个新版本试用，确认兼容性后逐步迁移。旧版本虽然稳定，但维护成本会随着时间推移越来越高。

SQL Prompt 9.0是个让我又爱又恨的工具——爱它帮我省下了大量写SQL的时间，恨它偶尔闹脾气影响工作节奏。但只要把许可证机制、网络校验和进程加载路径这几个关键节点搞明白，这些"突然无法使用"的问题，其实都是可以快速定位并解决的。希望这篇文章能帮到正被SQL Prompt 9.0折磨的你。下次遇到插件挂了，别慌，按上面的顺序慢慢排查即可。