navicat 不支持真正的多级文件夹嵌套，仅提供一级分组功能，所有组均为平级并列显示，无父子层级关系；可通过连接分组与表分组组合模拟逻辑多级结构，官方推荐此方案。
navicat 本身不支持嵌套多级文件夹（比如“项目a > 模块b > 测试环境”这样的三级结构），所谓“多级文件夹”是用户对分组功能的常见误读——它只允许一级分组（即“组”内不能建子组）。
Navicat 的“分组”不是文件系统式目录
你右键数据库连接 → “新建表组”，或在“管理连接”中右键连接 → “新建组”，创建的都是平级容器。Navicat 不提供折叠/展开子组、拖拽进子组、路径式命名等行为。所有组都并列显示在导航窗格顶层，没有父子层级关系。
常见错误现象包括：
- 试图把一个已存在的组拖进另一个组，结果只是移动了该组的位置，而非嵌套
- 给组命名为
finance/dev/staging，期望能按斜杠自动分层——实际只显示为完整字符串，无解析逻辑 - 导出配置后发现
.ncx或.ncw文件里根本不存在parent_group_id这类字段
用连接分组 + 表分组组合模拟多级逻辑
虽然不能真嵌套，但可通过两个维度叠加实现近似效果：连接层面按项目隔离，表层面按模块归类。这是 Navicat 官方推荐且唯一稳定可行的“逻辑多级”方案。
使用场景：
- 团队同时维护 finance_v1、finance_v2、marketing 三个独立项目
- 每个项目下需区分
core、log、archive等表集合
实操建议：
- 为每个项目单独建一个数据库连接，命名如
finance_v2_prod、marketing_staging - 在每个连接内部，右键 → “新建表组”，命名为
core_tables、log_tables - 用颜色标记连接：右键连接 → “编辑连接” → “外观” → 选色，让 finance 相关连接统一为蓝色，marketing 为绿色
- 把同项目多个环境连接（dev/staging/prod）拖入同一个“管理连接”中的自定义组，例如建个叫
Finance Env Group的连接组，仅作视觉聚类
为什么别碰 .ncw 文件手动编辑或 Git 管理
.ncw 是 Navicat Cloud 工作区的二进制序列化文件，结构封闭、无公开 schema。即使你用 hex 编辑器强行修改，下次 Navicat 启动时大概率报错 Invalid workspace file format 并自动重建空文件。
容易踩的坑：
- 把
.ncw提交到 Git：无法 diff，每次变更都显示为“binary files differ”，完全失去版本可追溯性 - 多人共用同一
.ncw：无锁机制，后保存者直接覆盖前者的全部分组和图表布局 - 跨 Navicat 版本（如 16.2 ↔ 17.0）打开同一
.ncw：提示Unsupported workspace version，且无法降级导出
真正需要协同组织的团队，应直接跳过 .ncw，改用 Navicat On-Prem Server 创建项目空间，在那里才能定义带权限的、可邀请成员的、支持审计日志的“逻辑多级”结构。
替代方案：用外部工具补位分组逻辑
当 Navicat 内置能力触顶时，最务实的做法是把分组规则外移，只把 Navicat 当作执行终端。
实操建议：
- 用 Markdown 维护一份
navicat-structure.md，明确写清：finance_v2_prod连接下哪些表属于payment_core组，谁负责维护 - 将表分组映射关系导出为 JSON（通过 Navicat 的“导出组为 SQL”不现实，但可用 Python 脚本解析
.ncx文本片段——注意：仅限 Navicat Premium 17+ 的部分 XML 化配置） - 在 Confluence 页面嵌入 Navicat 截图 + 表组说明，并设置页面权限，确保只有 finance 团队能查看 finance 相关分组约定
复杂点不在怎么建文件夹，而在于谁有权决定某张表该归入哪个组、变更是否同步通知下游服务——这些 Navicat 从不记录，必须靠外部流程兜底。
