navicat 17 的“标签”实为基于 uri 和云项目的逻辑分类机制，通过将查询、bi 工作区等保存至指定云项目（如“风控审计”）实现分类，项目名即语义标签；不支持手动打标签或本地 vgroup.json 同步，所有操作须经 navicat cloud 或 on-prem server 中转，且跨项目保存为独立副本，修改需手动同步。
navicat 17 的“标签”功能不是 ui 上的视觉标记，而是通过 uri + 云存储（navicat cloud 或 on-prem server）实现的逻辑分类，直接拖拽或保存即生效，不依赖本地配置文件。
Navicat 17 标签功能实际指代的是 URI 共享机制
很多人在 Navicat 17 界面里反复点击右键找“添加标签”菜单，结果发现根本不存在——因为 Navicat 17 并没有传统意义的标签系统。所谓“用标签分类资源”，本质是利用 Navicat URI 将对象（如查询、BI 工作区、模型）绑定到特定项目，并通过项目成员权限控制访问范围。每个项目就是一个隐式“标签”。
- URI 形如
navicat://cloud/project/abc123?object=bi-workspace&id=xyz789，其中project/abc123就是分类锚点 - 你不能手动给单个表或连接打“支付模块”“风控模块”这类标签；但你可以把相关
查询保存进名为“风控审计”的项目，这就完成了分类 - 项目名称就是团队约定的语义标签，比如
prod-v2.3、analytics-q2、legacy-migration
如何把一个查询归入指定“标签”（项目）
操作路径非常固定，且必须经过云服务中转：
- 先确保已登录
Navicat Cloud或已连接Navicat On-Prem Server - 打开目标查询 → 点击顶部菜单
文件 → 保存到云 → 选择已有项目（或新建项目） - 若选“新建项目”，输入名称如
用户增长分析，它就成为后续所有存入该项目的对象的统一分类标识 - 保存后，该查询在导航窗格中会出现在
Navicat Cloud/On-Prem Server节点下对应项目内，而非原始数据库连接下 - 其他成员只要被添加为该项目成员，就能立刻看到并使用这个查询
为什么不用 vgroup.json 做团队资源分类
因为 vgroup.json 是纯本地文件，只影响单机 Navicat 的左侧导航栏显示，无法同步到他人环境。团队协作场景下强行共享该文件极易出错：
- 不同版本 Navicat 对
vgroup.json的version字段兼容性不一致（如 1.0 vs 1.1） - 路径中含中文用户名时，Windows 下 JSON 文件可能因编码问题导致分组丢失
- 一旦某人误删或覆盖了
vgroup.json，整个分组体系就崩溃，且无回滚机制 - 它无法控制权限——哪怕你把
vgroup.json发给同事，他也看不到你数据库里的真实数据，只是看到一堆空壳分组
BI 工作区和模型工作区的“标签化”实践要点
这两类对象天然适配 URI 分类，但要注意几个硬性前提：
- BI 工作区必须先保存到
Navicat Cloud或On-Prem Server，才能生成可分享的 URI；本地保存的.nbw文件不支持跨设备识别 - 模型工作区在 Navicat 17 中需启用“模型工作区”功能（默认开启），且保存时必须选“保存到云”，否则不会出现在项目节点下
- 分享前务必检查项目成员权限：只设
可以阅读的成员无法修改 BI 图表或模型关系，但能刷新和查看 - URI 链接本身不包含敏感信息（如密码、IP），但访问者必须拥有对应数据库连接权限，否则打开后仍提示连接失败
真正容易被忽略的是：URI 分类不是“贴标签”，而是“建入口”。同一个查询可以同时存在于多个项目中（比如既在 dev-sandbox 又在 reporting-daily），但每次保存动作都是一次独立的复制操作，后续修改不会自动同步——你得手动在每个项目里分别更新。
