建表时必须显式声明JSON类型，不可依赖Navicat自动推断或用LONGTEXT替代；插入前需确保JSON字符串符合RFC 7159规范且通过JSON_VALID()校验。
建表时手动声明 JSON 类型，别信自动推断
navicat 在「新建表」界面里下拉字段类型时能看到 json，但前提是连接的 mysql 版本 ≥ 5.7.8 且当前用户有权限。如果下拉列表里没有 json，先执行 select version(), @@sql_mode; 确认版本和 sql 模式（不能含 strict_trans_tables 以外的严格模式干扰）。
常见错误是建表时让 navicat 自动猜类型——比如导入 csv 后它把一列标为 varchar(255)，后续再改类型会失败：mysql 不允许直接从 varchar 转成 json，除非所有值都通过 json_valid() 校验。
CREATE TABLE 语句中必须显式写 JSON，不是 LONGTEXT
即使你打算存大 JSON，也不能用 LONGTEXT 代替 JSON。两者底层存储不同：JSON 类型会自动校验语法、标准化空格/键序，并支持 ->、JSON_EXTRACT() 等原生函数；而 LONGTEXT 只是存字符串，查 data->'$.name' 会返回 NULL 或报错。
正确建表示例：
CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, profile JSON );
如果已有表需加 JSON 字段，用 ALTER TABLE users ADD COLUMN settings JSON;，不要省略 JSON 关键字。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
插入前确保字符串是 RFC 7159 合法 JSON
Navicat 表格界面双击编辑 JSON 字段时，输入 {"name": "张三", "age": 25} 是可以的，但输入 {name: "张三"}（键没引号）或 {"name": "张三",}（尾逗号）会静默失败或存成 NULL。
安全做法：
- 在 Navicat 查询窗口先测试：
SELECT JSON_VALID('{"name": "张三"}');返回1才可靠 - 避免粘贴带 BOM 头的 UTF-8 文件内容（常见于 Windows 记事本保存的 JSON）
- 数值不用引号，字符串必须双引号，布尔值写
true/false，别用"true"
虚拟生成列依赖 JSON 字段，但 Navicat 不自动识别其依赖关系
比如你建了 v_name VARCHAR(100) AS (JSON_UNQUOTE(JSON_EXTRACT(profile, '$.name')))，这个 v_name 是虚拟列，值由 profile 实时计算。Navicat 的表结构界面不会高亮这种依赖，但它真实存在——删掉 profile 字段会导致 v_name 失效甚至建表失败。
注意点：
- 虚拟列定义里必须用
JSON_EXTRACT+JSON_UNQUOTE组合，否则带引号 - Navicat 导出表结构时可能漏掉
STORED或VIRTUAL关键字，手动补全 - 同步到其他库时，目标库也要支持生成列（MySQL ≥ 5.7.6）
NULL——往往因为源数据混了单引号、BOM、或 Navicat 连接参数没开 allowPublicKeyRetrieval=true（尤其 MySQL 8.0+ 用 caching_sha2_password 认证时）。
