WebStorm 2023.3+ 通过粘贴合法 JSON 到 .ts 文件顶层作用域触发接口生成，支持编辑接口名和自动转换字段命名规则，但类型推断有限且不解决运行时数据映射。
WebStorm 自带的 JSON to TypeScript 功能在哪
WebStorm 2023.3+ 版本起，原生支持从 JSON 字符串一键生成 TypeScript 接口，但**不叫“JSON to Interface”菜单项，也不在右键上下文里直接显示**。它藏在「Paste」动作中——只要你复制了一段合法 JSON，再在 .ts 文件里执行粘贴（Ctrl+V / Cmd+V），就会弹出智能粘贴选项。
关键点：必须粘贴到一个已打开的 .ts 文件中，且光标位于顶层作用域（不能在函数体、对象字面量或字符串内部）。否则菜单不会出现。
常见错误现象：
– 粘贴后直接变成字符串字面量，没弹窗 → 光标位置不对，或文件不是 .ts 后缀
– 弹窗里只有 “Paste as Plain Text” → JSON 格式非法（比如末尾多逗号、单引号、未转义双引号）
– 生成的接口名是 RootObject 或 Item → 原始 JSON 没有顶层 key 名，或结构太扁平（如纯数组）
粘贴时选 “Paste as JSON” 后怎么控制字段类型
WebStorm 的转换基于 JSON 值推断类型，但对边界情况处理有限。它默认把 "123" 当作 string，不会自动转成 number；"true" 也不会识别为 boolean。这意味着：
- 数值型字符串（如
"2024"、"3.14"）→ 一律生成string类型字段 - 布尔字符串（如
"true"、"false"）→ 仍为string，不是boolean - 空数组
[]→ 推断为any[]，而非更具体的类型 - null 值 → 字段会带
| null联合类型，但若某次出现 null、另一次是 string，会合并为string | null
所以，如果你的 JSON 来自后端 API，且明确知道 "year": "2024" 应该是 number，生成后必须手动改类型，并配合运行时转换逻辑（比如用 map + parseInt），不能只靠接口定义保类型安全。
为什么生成的接口名是 RootObject，如何改
接口名由 WebStorm 根据 JSON 结构自动生成，规则是：
- 如果 JSON 是对象且含顶层 key（如
{"user": {...}}），会尝试用user→User（PascalCase 化） - 如果 JSON 是纯对象字面量（
{"name": "a", "id": 1}），默认名是RootObject - 如果 JSON 是数组（
[{"x":1}]），默认名是Item
你可以在弹窗里直接编辑接口名（输入框在顶部），但注意：
– 名字必须以字母或 $ 开头，不能含空格、短横线、数字开头（如 2nd-data 会被截断或替换）
– 若项目中已存在同名接口，WebStorm 不会警告，直接覆盖写入，可能引发编译错误
– 修改名后，嵌套对象的子接口名仍按默认规则生成（如 User 下的 address 字段会生成 Address），无法批量定制
生成后字段名含短横线或空格怎么办
JSON 中字段如 "first-name"、"is_active"、"3rd_attempt"，WebStorm 会自动标准化为合法 TS 标识符：
– "first-name" → firstName（kebab-case → camelCase）
– "is_active" → isActive（snake_case → camelCase）
– "3rd_attempt" → Attempt（数字开头被丢弃，只剩 rd_attempt → RdAttempt？实际常退化为 Item）
这个过程不可配置，也无预览。如果原始字段语义关键（比如 "e-mail" 和 "email" 含义不同），生成后必须人工核对并还原命名，再用 @ts-ignore 或映射函数做运行时字段对齐——接口只是类型契约，字段名不等于序列化键名。
真正容易被忽略的是：生成的接口只解决「结构描述」，不解决「运行时数据映射」。哪怕接口完美，fetch 回来仍是字符串数字，不手动 parse 就永远过不了类型检查。别让漂亮的接口掩盖了数据落地那一步的真实工作量。
