navicat cloud 不提供空间不足告警功能，同步状态界面仅在失败或跳过时被动显示 quota exceeded，且无实时提醒、无配额占比统计、不区分团队/个人配额、用量数据有延迟；需通过清空回收站、定时调用api监控配额、禁用非必要同步路径、清理.nbi/.ndm等大体积文件来主动管理。
Navicat Cloud 本身不提供空间不足告警功能，无论你翻遍设置、日志或 API 文档，都找不到任何开关、钩子或配置项能触发邮件、弹窗或 Webhook。
为什么 Cloud Sync Status 里看不到“配额超限”实时提醒
Navicat Cloud 的同步状态界面（Tools → Cloud Sync Status）只在同步失败或跳过时才显示 quota exceeded，但这个提示：
- 不主动弹出，需手动打开并逐条点开 Skipped/Failed 条目才能看到
- 不聚合统计，不会告诉你“当前已用 98% 配额”
- 不区分是团队总配额还是个人子配额（协作版按团队账户统一计费）
- 日志缓存有延迟，刚清空回收站后，Account Info 里的用量数字可能仍显示旧值，必须手动点 Refresh 才更新
能实际落地的监控替代方案
既然原生无告警，只能靠外部手段捕获配额逼近信号。以下动作可在 10 分钟内上线，且不依赖 Navicat 内部机制：
- 登录 portal.navicat.com，进 Trash 栏清空软删除项——这是最快速释放空间的动作，30 天软删期一过即自动计入配额
- 在本地写一个定时脚本，每小时执行一次：curl -s "https://api.navicat.com/v1/account/info" -H "Authorization: Bearer $TOKEN"，解析返回 JSON 中的 used_bytes 和 total_bytes，当比值 ≥ 0.92 时调用 mail 或 curl 推送到企业微信机器人
- 检查桌面端 Sync Folders 设置，禁用那些只存临时 SQL 草稿、历史备份、调试片段的路径——这些文件虽小，但数量多、更新频，极易悄悄吃掉上百 MB
BI 工作区和模型文件是隐形配额杀手
很多人以为“.sql 文件”占空间最多，其实真正危险的是：.nbi（BI 工作区）和 .ndm（模型工作区）。它们包含图表快照、数据预览缓存、字段映射元数据，单个文件压缩前常达 5–8MB。更麻烦的是：
- 这类文件修改后不会覆盖上传，而是新增版本（类似 Git commit），旧版本仍计入配额
- 即使你在 Navicat 里删掉一个 BI 报表，它只是进回收站，30 天内仍占用空间
- .pipeline 和 .snippet 文件虽小（几十 KB），但若团队每人每天存 10+ 个调试用片段，一个月就是 300MB+
真正容易被忽略的是：配额计算基于原始字节，不是压缩后大小；加密存储还会额外增加 3–5% 体积。别等同步“看起来成功”才检查——静默跳过才是常态。
