Navicat Premium 17 数据库管理实战指南：升级、安装与高效运维

Navicat Premium 17 我从前几个测试版就开始在公司电脑和个人笔记本上轮着用，到现在算是把日常的数据库管理操作全部切了过去。这篇指南不是把官网文档重新抄一遍，而是把我在实际使用中觉得最值得讲的几条主线串起来：版本升级的取舍、正经的安装授权路径、多数据库连接管理、查询和导入导出的效率习惯、数据和结构同步、模型图表，以及最后真实遇到过的坑。适合刚准备入手的后端开发、DBA、数据分析师，还有那些在旧版本上犹豫要不要升的人。

说实话，数据库客户端这个品类，近几年变化真的不算大。周围很多同事还用着两三年前的版本，功能上确实不耽误事。但 Navicat Premium 17 最大的改变不是某一个杀手级功能，而是整套操作手感在往现代工具靠拢——深色模式更彻底、多标签页更顺、连接切换和代码补全这些细节都舒服了不少。尤其你如果同时维护 MySQL、PostgreSQL、MongoDB 甚至 Redis，用 Premium 的优势就很明显：不用在多个客户端之间来回切，一个侧边栏就能看到所有库的状态。

我会尽量写实操层面的东西，包括一些快捷键习惯、踩坑记录和配置建议。你看完如果照着操作，应该能把 17 真正用起来，而不是当成一个改了界面的老版本。

1. 先搞明白：17 比老版本多了什么，值不值得升

1.1 从老版本一路用过来，17 的变化都在细节里

我最早用的是 Navicat for MySQL，那时候还是 9、10 的版本，工具还是按数据库类型拆开的，MySQL 版、PostgreSQL 版、Oracle 版各装一个。后来用上 Premium，才算是把多个数据库类型收进同一个软件里。17 这代，我体感上最大的变化不是某个按钮换了位置，而是整个应用的响应速度和视觉密度明显打磨过。

深色模式是我最惊喜的部分，不是简单把界面涂黑，而是树形菜单、SQL 编辑器、结果集网格的配色都重新调过，长时间盯屏的疲劳感确实比老版本低。以前我开着浅色界面写 SQL，到下午眼睛就开始发酸，现在切到深色后再也没觉得屏幕太刺眼。多标签页的体验也好了不少，在一个标签页里连接 MySQL，另外一个标签页连接 MongoDB，切换的时候不会重新加载半天，比 16 更跟手。

不过我要提醒一句：如果你是抱着"17 会多出什么惊天动地的新功能"的心态来升级，大概率会失望。Navicat 这类工具的核心能力，比如连接管理、查询编辑、数据同步、模型设计，早在几代之前就已经很成熟了。17 属于在成熟框架上做体验升级的版本，它的价值是让"天天都要用的操作"变得更顺，而不是让你干什么全新的活。

1.2 升级前必须核对的几件事

第一个要核对的是操作系统支持。Navicat 17 对 Windows、macOS、Linux 都有对应版本，但 macOS 上分为 Apple Silicon 和 Intel 两个安装包，如果你在 M 系列芯片的 Mac 上装了 Intel 版，虽然能用 Rosetta 转译跑起来，但效率和新版的原生适配体验还是有差距，建议优先下载 Apple Silicon 原生包。Linux 下还分 deb、rpm、tar.gz 等格式，别下错。

第二个是授权类型。Navicat 的授权有订阅和永久许可两条路线，订阅版升级新版本通常不需要额外花钱，永久许可则要看当初购买时是否包含版本升级权益。你从 16 升到 17，最好先去官网登录账号确认一下升级资格，别等安装完成打开一看才发现授权不覆盖新版本，那时候再回头找销售就很被动了。我在公司踩过一次这个坑，老同事离职前留下了永久版授权，结果新版本怎么都验证不了，最后翻邮件才发现授权只到 16 的某个小版本。

第三个是连接配置的迁移。老版本里存的连接信息是可以导出的，建议在升级之前先把连接导出成 .ncx 文件，等装好 17 之后再导入。这样所有的主机地址、用户名、端口都不用重新填，能省下不少事。升级的过程中保留老版本安装包，等 17 验证完关键流程稳定了再卸载，给自己留一条退路。

1.3 我的建议：哪几类用户不用急着升

如果你的工作就是连一个 MySQL 库，写写查询、看看数据，老版本完全够用，没必要为了升级而升级。团队里如果还在用老版本共享备份计划、任务调度文件，也要先确认 17 能不能兼容这些历史配置，别升完才发现协作链路断了一截。还有一种情况是电脑配置比较老，内存只有 8G 左右，打开大型模型、大数据量结果集时，17 的现代界面反而可能比极简风格的老版本更吃资源，这种情况下用着顺手的老版本反而是更好的选择。

反过来，如果你平时要管理多种数据库、需要在不同项目环境之间来回切换、经常做结构和数据同步，那 17 的体验提升是能直接感受到的。这种投入不像换个数据库那么伤筋动骨，至少从我个人跑了一两个月的实际感受来看，稳定性是在线的。

2. 安装和授权：正经渠道怎么搞，别碰来路不明的补丁

2.1 官方下载与安装包选择

安装第一步永远是去官网。Navicat 这套软件虽然用起来简单，但它直接面对你的数据库连接信息，如果安装包被人动了手脚，等于把你所有服务器的钥匙交到了别人手里。官网下载页会列出 Windows、macOS、Linux 的平台选项，选对系统架构下载即可。下载完的安装包，如果不放心，可以核对一下数字签名或校验信息，至少确保文件在传输过程中没被替换。

Windows 下安装基本没有特别需要动脑的地方，一路 Next 就完了。macOS 下拖拽到 Applications 即可。Linux 需要根据发行版选择包格式，比如 Debian/Ubuntu 系用 deb，Fedora/CentOS 系用 rpm。有一点要提醒：Navicat 的安装包自带数据库客户端所需的常见组件，但如果你使用比较小众的数据库引擎，首次建立连接时可能会提示缺少对应驱动组件，按提示补齐组件、重新测试连接即可，不是软件出了问题。

2.2 试用、订阅、永久许可：授权方式怎么选

Navicat 17 继续沿用订阅和永久许可并行的路线，个人版、团队版、企业版的入口在官网上都有，具体价格和包含的数据库引擎数量，以官网商城为准。我的建议是：如果你只是自己一个人用，个人订阅或永久许可就够了；如果公司有多人要协作，团队版在连接共享、模型协作上会更省心，不用靠微信群口头传连接配置。

安装完成后第一次打开，一般会让你选择试用或者输入许可证。官方试用版是全功能的，也就是说连接、查询、同步、模型、计划任务这些能力都开放，不会提前把核心功能锁起来。你可以用试用期把关键流程完整跑一遍，再决定买什么级别的授权，这个思路比先拍板买再后悔要稳得多。试用时间到了之后，在帮助菜单里打开注册窗口，填入许可证密钥，或者登录 Navicat 账号验证授权，状态变成有效就能继续使用。

说到许可证，我想专门提一句：不要费心去找所谓的注册码、注册机。网上流传的那种来路不明的补丁，我见过太多人为了省一点授权费给 Navicat 打上去，结果客户端启动的同时，后台多了一堆未知进程。Navicat 这种工具能直接读取你的数据库地址、账号、密码，用不干净的版本等于把你所有库的钥匙交出去，这个风险远比授权费本身要大。

2.3 安装阶段常见问题

macOS 用户最常遇到的是下载完成后系统提示应用已损坏或无法验证开发者。这种情况通常不是安装包真的坏了，而是 Gatekeeper 安全策略在拦路径，右键点击应用图标再选择打开，或者到系统设置的隐私与安全里点击允许，基本上都能解决。不要用网上教的那种清空扩展属性的命令强行绕过安全策略，正规渠道下载的安装包用的是正常签名，不需要那些操作。

Windows 下偶尔会遇到杀毒软件误报，尤其某些第三方杀软对加壳安装包特别敏感。只要你是从官网下载的文件，可以核对一下签名信息确认文件没被篡改，再考虑加入信任区。真正需要警惕的，是那种从论坛、网盘下载下来、号称免安装绿色版的压缩包，这类资源才是病毒重灾区。Linux 下如果打开后闪退，多半是缺少桌面运行依赖，按官方文档把 GTK 相关依赖补上就行了。

3. 连接管理的正确打开方式：多库、跳板机、跨设备同步

3.1 新建连接：连接名、端口、字符集这些细节别将就

新建连接是使用频率最高的入口，但很多人的连接名就是一串乱起的英文，过一个月自己都不知道连的是哪个库。我的习惯是用"项目-环境-数据库类型"的命名方式，比如商城-生产-MySQL、商城-测试-PostgreSQL，这样侧边栏扫一眼就能定位。连接名看着是小事，等你有几十个连接、还要在小屏幕的笔记本上找目标库的时候，就知道这个习惯有多值钱了。

找一个比较完整的参考表，常见数据库在 Navicat 里新建连接时的默认配置大致如下：

新建连接窗口里，除了常规的主机、端口、用户名、密码，下面的高级选项也要看一眼。字符集这一项我建议直接选 utf8mb4，尤其是 MySQL 8 之后的库，utf8mb4 对 emoji 和生僻字的支持更完整。连接超时时间不要设得太短，默认值有时候在跨网络环境下不够用，等到你连接生产库经常秒断的时候再来改就晚了。

3.2 通过跳板机访问内网生产库

很多公司的生产数据库并不直接暴露公网，只开放一台跳板机或者堡垒机，让你先登录到跳板机网络里，再访问内网数据库。Navicat 的连接配置里专门有 SSH 选项，就是干这个用的。我第一次用的时候还闹过笑话，以为跳板机的地址应该填在主机那栏，结果连了半天连不上，后来才发现逻辑正好相反。

正确的配置方式是：常规页面里填内网数据库的真实地址，比如10.0.1.10；然后切到 SSH 页面，勾选使用 SSH 连接，再填跳板机的公网地址、端口、SSH 用户名，认证方式可以选择密码或私钥。SSH 登录的用户是跳板机上操作系统层面的账号，和数据库用户完全是两回事，不要在 SSH 用户名里填数据库账号。如果使用私钥登录，私钥文件建议存到本地固定的目录，不要放在临时目录里，文件的权限也不要放开，私钥权限太松会被 SSH 拒绝加载。

这种连接方式对 Windows、macOS、Linux 都适用，配置完成后点测试连接，Navicat 会先尝试建立 SSH 连接，再通过 SSH 转发访问数据库端口。只要能通，说明这一层的链路是完整的，接下来再排查数据库账号问题就有方向了。

3.3 连接配置的导出、导入与 Navicat Cloud 同步

换电脑或者重装系统的时候，最痛苦的不是重装 Navicat 本身，而是几十个连接要一个个手敲回去。Navicat 的文件菜单里有导出连接功能，可以把当前列表里的连接信息导出成.ncx文件，换到新机器上再用导入连接功能选同一个文件，就能快速恢复。需要注意，连接文件里如果保存了密码，这个文件就等同于一把钥匙，不要随手放到 Git 仓库、共享网盘或者聊天记录里，建议放进密码管理器或者加密的存储空间。

Navicat Cloud 是另一条路，注册并登录 Navicat 账号之后，可以把连接信息、代码片段、模型同步到云端，再在另一台电脑上拉取下来。这个方案对个人跨设备使用很方便，但公司安全策略比较严的时候，不建议把生产环境连接信息放到任何第三方云端，哪怕官方声称做了加密，企业审计也不会轻易放行。

还有一个容易被忽略的细节：连接名在导出导入之后最好保持一致。因为 Navicat 里已经保存的查询文件、模型文件，很多是绑定到连接名的，如果导入到新电脑后连接名变了，这些文件打开时会找不到对应的库，得重新指定连接，很折腾。

4. 查询、编辑、复用：把日常工作效率拉满的三个习惯

4.1 SQL 编辑器：从“能写”到“写得顺”

Navicat 的 SQL 编辑器很多人都在用，但大多数人的用法其实只发挥了它一半的能力。最核心的习惯是：永远不要直接点运行全部的按钮，而是先用鼠标选中要执行的那一段 SQL，再点击运行。这样即使编辑器里有几条调试用的历史语句，也不会误执行，尤其面对生产库的时候，这个习惯能避免很多低级事故。

自动补全是我觉得 17 里最顺手的改进之一，输入表名的一部分，下拉提示基本能跟上打字速度，字段名、别名、函数名都能补。格式化的功能被低估了，从同事那里接手一段几百行的复杂查询时，右键格式化一下，缩进和换行瞬间清晰，再去梳理表之间的关联会轻松很多。执行计划也很好用，选中一条慢查询，点击工具栏上的解释按钮，就能看到每一步的索引使用情况、扫描行数、临时表使用情况，排查慢查询效率比在命令行里翻输出高不少。

查询结果区域还隐藏着一个小技巧：结果集本身自带排序和筛选功能，不用回到 SQL 编辑器改 ORDER BY 或者 WHERE，直接在表头上点筛选图标就能做二次过滤。这种临时性的筛选对定位数据非常有帮助。

4.2 查询构建器和结果集直接编辑，能少写一半 UPDATE

查询构建器在 Navicat 里存在很久了，但实际用的人不多。它的操作逻辑很像可视化建模工具，把左侧的表拖进画布，勾选要取出的字段，设置关联关系，再在下方配置 WHERE 条件和排序，点击确定之后，Navicat 会自动生成一段完整的 SELECT 语句。这个功能对 SQL 基础一般的人非常友好，就算你精通 SQL，用它来快速搭一个多表 JOIN 的底稿，再手动优化优化，也比从零开始敲要快。

比查询构建器更让我依赖的，是结果集的直接编辑能力。普通单表查询出来的结果，每行数据是可以在网格里直接双击修改的，改完点提交按钮，相当于帮你执行了一条 UPDATE。我经常用它来快速修正测试环境里的脏数据，比打开命令行写一条 UPDATE 再回来看结果高效得多。但要注意，多表 JOIN 的查询结果、聚合结果、带 DISTINCT 的查询结果，都是不可编辑的，这是数据库语义决定的，不是 Navicat 的限制。在有变更审批流程的系统里，即使网格能改，也走正规变更流程，工具顺手归顺手，流程边界要守住。

4.3 代码片段与保存的查询，把重复劳动变成一次点击

数据库巡检、周报统计、临时对账这种事，SQL 其实翻来覆去就是那十几条，只是表名和日期范围在变。Navicat 的代码片段功能就是为这种场景准备的，在 SQL 编辑器里选中一段常用的 SQL，右键添加到代码片段，给它取一个能识别的名字，比如"昨日订单量统计"，下次要用的时候从代码片段面板里点一下就能插入编辑器。

我自己的习惯是把几种常用模板都存进去，比如分页查询模板：

SELECT * FROM `#TABLE#` WHERE `created_at` >= NOW() - INTERVAL 1 DAY ORDER BY `id` DESC LIMIT 100;

用的时候把表名和查询条件替换一下就行。保存的查询则是更偏"业务场景"的概念，比如每个季度要跑的数据报告，可以把完整的 SQL 保存成查询文件，下次直接在左侧对应的连接下点开运行，不用重新写一遍，也不用担心别人拿错脚本。长期积累下来，这部分才是 Navicat 里最值钱的资产。

5. 数据迁移、结构同步、备份计划：别再用原始 SQL 硬搬

5.1 数据传输：跨库搬家时的正确姿势

工具菜单里的数据传输，是我平时用得最多的功能之一。它可以把一个库的表结构和数据整体搬到另一个库，源库和目标库甚至可以是不同类型的数据库，比如从 MySQL 迁移到 PostgreSQL，字段类型会自动做映射转换。选好源连接和目标连接之后，可以看到一个对象列表，默认是全部表都选中，你可以只勾选需要的表，避免把没用的历史表也搬过去。

实际操作里我要多提醒一句：跨数据库类型迁移时，不要因为向导提示"完成"就掉以轻心。MySQL 的 TINYINT、ENUM 这类类型在 PostgreSQL 里不一定有完全对等的映射，迁移完成后要抽查几个关键表的字段类型、主键、自增序列是否正常。大批量数据迁移建议先在测试环境里选一个小表跑一遍，看看耗时和错误日志，再决定全量迁移的方案。目标库在迁移期间的磁盘 I/O 很可能被打满，这种操作尽量安排在业务低峰期，否则连带线上业务一起卡顿，就得不偿失了。

5.2 结构同步与数据同步：环境对齐的利器

结构同步解决的是"两个库结构不一致"的问题。你在测试环境改了一张表加了两个字段，想把这个变更同步到生产环境，手工去生产库执行 ALTER TABLE 是最容易翻车的，漏了一个索引、少改一个默认值，后面都要花时间填坑。Navicat 的结构同步功能会同时读取源库和目标库的表结构，把差异逐条列出来，生成对应的 ALTER 语句，你可以在执行前看到完整的变更脚本，确认无误后再一键应用。

数据同步则是记录级别的比对。它会把两个库里的数据逐条比较，找出新增、修改、删除的记录，然后生成同步方案。这个功能在"测试库要复制一份生产数据"这类场景里非常有用，比先导出再导入要高效。不过无论是结构同步还是数据同步，我都建议先让 Navicat 把部署脚本生成出来，而不是直接点执行。生成的脚本文件本身就是变更记录，走完代码评审或者审批流程再执行，万一出了问题也能根据脚本审计还原路径。

5.3 备份还原与计划任务：定时备份的完整落地

Navicat 的备份功能对 MySQL 和 PostgreSQL 这种数据库来说，本质上是封装了 mysqldump 或 pg_dump 的命令行工具，好处是你不用在命令行里记参数，界面上勾一勾就能完成备份和还原。备份文件可以指定存放位置，也可以选择是否在备份里包含 DROP TABLE 语句。还原的时候，Navicat 会把备份文件里的结构重新执行一遍，选库时注意别还原错目标库。

定时备份要靠计划任务来实现。Navicat 里可以创建计划，指定要执行的备份、数据传输或者 SQL 脚本，频率可以按每天、每周、每月的粒度设置。比如让核心业务库每天凌晨两点做一次备份，保留最近七天的文件，这些都可以在计划里配置。但有个前提得认清：Navicat 的计划任务依赖 Navicat 进程在运行，关机或者客户端退出之后，计划不会自动补跑，所以关键库的备份最好还是用数据库原生的定时任务、系统 crontab 或者专门的备份平台兜底，把 Navicat 的计划当成多一道保险，而不是唯一的保障。

6. 模型设计、数据字典、图表展示：数据库不只是命令行

6.1 从已有库反向生成 ER 模型

接手一个遗留系统的时候，最头疼的就是文档缺失，数据库几百张表之间的关系只能靠猜。Navicat 的模型功能可以把现有数据库反向工程成 ER 图，右键一个连接或数据库，选择反向工程到模型，Navicat 就会读取表、字段、索引、外键关系，在画布上生成一张可视化的关系图。对梳理老系统、给新同学讲表结构，比甩一打开几百行的建表 SQL 要有用得多。

模型画布上也可以直接新建表、添加字段、画外键连线，设计完一个新模块的表结构之后，可以再把模型同步到数据库，生成真正的建表 SQL 去执行。这相当于把一个迷你版的数据建模工具嵌在了数据库客户端里，不用另开工具来回倒腾。我在设计新项目时比较喜欢先建模型，再同步到库，而不是直接写 CREATE TABLE，因为模型更容易让我从全局看到表之间的关系，少了字段命名前后不统一的问题。

6.2 数据字典输出：团队文档不用手写了

工具菜单里的数据字典，我愿称之为"交付文档神器"。选择要导出的数据库和对象范围，Navicat 会把每张表的字段名、类型、是否允许为空、默认值、注释、索引、外键关系整理成一份结构化的文档，支持输出为 HTML、PDF 甚至 Word 等格式。项目验收、技术交接、数据库评审的时候，直接拿这份字典就能说明问题。

不过这个功能有个前提：你平时得有写注释的习惯。如果建表的时候字段注释全是空的，导出的数据字典就是一大堆干巴巴的字段名，毫无可读性。反过来，如果你在设计阶段就给每个表和字段写清楚了注释，数据字典导出来基本就是一份可以直接交给业务方的数据库说明书。这个前期投入很小，回报是长期存在的。

6.3 图表与轻量仪表板：快速展示，别当正式 BI 用

17 这代把图表和仪表板的应用往下沉了不少，你可以基于表、视图或者自定义查询直接创建图表，生成折线图、柱状图、饼图这类常见可视化。小团队想看最近一个月订单趋势，不想把数据同步到外部 BI 平台，直接在 Navicat 里拉个查询生成图表就能看，这是它的价值所在。

但我要泼一盆冷水：这类图表本质上是直接查询业务库的数据源，如果多人同时高频刷新，会给数据库带来不必要的压力。我的建议是把它定位成"临时分析"和"轻量展示"工具，看数据趋势、做汇报前的快速摸底都很合适，但如果你要做正式的、长时间挂载的业务大屏，还是把数据同步到专门的可视化平台更稳妥。

7. 我用 17 这些日子踩过的坑和调优思路

7.1 MySQL 8 认证插件导致的连接失败

连接 MySQL 8 时报错 1251、2059 或者Authentication plugin 'caching_sha2_password' cannot be loaded，是很多刚升级到 17 或者刚接手新环境的人会遇到的问题。根因是 MySQL 8 默认用的认证插件是 caching_sha2_password，而客户端或者驱动版本比较旧的时候，只认识老的 mysql_native_password 认证方式。

解决思路分两步。第一步，把 Navicat 升级到最新版，新版本内置的驱动通常已经兼容 MySQL 8 默认认证，这是最干净的方案。第二步，如果服务端是老库，确实存在兼容问题，并且安全策略允许，可以在 MySQL 侧把某个用户的认证方式改回去：

ALTER USER 'your_user'@'your_host' IDENTIFIED WITH mysql_native_password BY 'your_password'; FLUSH PRIVILEGES;

需要说明的是，这只是一种临时兼容方案，新项目不建议用，因为 mysql_native_password 在新版本 MySQL 里已经逐步被官方边缘化了，长期来看还是要让客户端适配 caching_sha2_password。

7.2 中文乱码的排查链路

Navicat 里看到中文变成问号或者乱码，是另一个高频问题。很多人第一反应是改连接字符集，但乱码的根因可能有好几层。我的排查顺序是：先看数据库和表的字符集是不是 utf8mb4，再看连接属性高级里的编码是否和库一致，最后看数据源文件本身是什么编码。

最容易踩坑的是从 Windows 的 Excel 导出 CSV 再导入 Navicat 的场景。中文 Windows 系统下 Excel 导出的 CSV 默认经常是 GBK 编码，直接一路默认导入，中文必然乱码。解决办法是在导入向导选择源文件的时候，手动把文件编码改成 GBK，预览区里的中文变成正常显示之后，再继续下一步操作。已经乱掉的数据不要反复改字符集去试，先确认源头有没有坏，源头是好的，导入设置对了就能还原；源头已经写坏，后面再怎么调都是空的。

7.3 大数据量场景下的卡顿与超时

查询几十万行数据的时候，Navicat 的结果集网格有可能会卡顿甚至长时间无响应。这不是 Navicat 独有的问题，任何数据库客户端在渲染超大结果集的时候都会有性能瓶颈。我的经验是：生产环境的查询永远先加 LIMIT 再执行，尤其在排查数据问题时，你需要的往往只是前一百条记录，而不是全表数据。

大批量导入数据时，如果中途失败，报错会停在某一条记录上。可以先勾选出错继续的选项，让任务跑完，再根据日志定位脏数据。这个方法适合首次全量导入，不适合增量同步，增量数据一旦跳过就会产生永久性缺口，还是应该先修正数据再重新跑。如果 SQL 脚本跑的时间很长，注意连接属性里的超时时间不要设得太小，同时也要关注数据库服务端的 wait_timeout 配置，两边不匹配的话，脚本跑到一半连接被服务端断开，才是最冤枉的失败。

7.4 换电脑、升级版本前的资料备份

写到最后这部分，算是给自己的一个提醒。换电脑或者升级大版本之前，除了导出连接文件，保存的查询、代码片段、模型这些存量资产也要记得备份。连接信息可以重新填，但那些累积了几年的查询脚本和模型关系图，一旦丢了很难重建。我更习惯定期把整个 Navicat 的用户配置目录做一次压缩存档，Windows 下通常在%APPDATA%\PremiumSoft\Navicat Premium 17\，macOS 下在~/Library/Application Support/PremiumSoft/Navicat Premium 17/，具体以你自己机器上的实际目录为准。计划任务这种动态配置，最好手工记录一下内容和频率，或者干脆用数据库原生定时任务重做一遍，比依赖单个客户端更稳。

最后分享一个我自己的小习惯：我会在 17 里把常用生产库的查询都保存成只读账号的查询文件，日常巡检直接点开运行，绝不拿管理账号跑业务查询。工具再顺手，权限边界和流程习惯才是保障数据安全的关键。希望这篇指南能帮你把 Navicat Premium 17 真正用起来。