近日，不少Flutter开发者在日常开发中遇到了一个颇为吊诡的现象：当他们在VS Code中编辑本地化资源文件（.arb）时，编辑器会在那些以@开头的元数据条目上不断弹出红色波浪线，并提示“Incorrect type. 'string' expected”（类型不正确，应为“string”）。然而，只要开发者运行Flutter官方提供的本地化生成命令flutter gen-l10n，整个构建流程却毫无意外地顺利完成，生成的Dart代码也完全符合预期。这种“一边报错、一边正常”的矛盾局面，迅速在开发者社区中引发了热议。
.arb文件是Flutter国际化框架中的标准资源格式，全称为“Application Resource Bundle”。它采用JSON结构，用来承载不同语言下的文本资源及相应的元数据。在Flutter的国际化约定中，普通的key对应的是简单的字符串值，而像@title、@description这类以@符号开头的条目，则属于资源元数据。它们的作用并非提供翻译文本，而是描述资源本身的信息，如说明文案、占位符的用法等。因此，这类元数据键的取值可以是一个字符串，也可以是一个更复杂的对象结构，具体形态由开发者根据需求灵活定义。
问题恰恰出现在这一灵活机制上。VS Code内置的JSON语言服务在对.arb文件进行结构校验时，似乎对@元数据条目的类型认定过于单一。当这些条目的值被写成对象形式时——这在Flutter的本地化实践中十分常见，用来标注占位符的type和example——VS Code便固执地认为此处应当是一个普通字符串，从而抛出类型不匹配的提示。与此同时，flutter gen-l10n作为官方工具链的一部分，对.arb文件的结构解析完全遵循Flutter框架的实际语法规范，自然能够顺利识别并处理这些元数据对象。两者对同一份文件的不同解读，正是造成这一矛盾现象的根源。
不少开发者最初被这一报错弄得心神不宁，以为自己的项目配置出了差错。在仔细检查并确认构建产出与运行时表现均无误之后，他们才逐渐意识到，这很可能是VS Code端Flutter/Dart扩展或JSON Schema定义滞后于Flutter官方规范所致。在GitHub等开源社区的讨论中，有开发者指出，VS Code所使用的.arb文件Schema可能并未完整覆盖Flutter元数据条目的所有合法形态，或者其默认的校验策略错误地将所有@条目值统一视为普通字符串。而官方工具链则始终以运行时解析的视角处理文件，二者在工具设计理念上的差异，最终以这种“刺眼”的红色波浪线形式呈现在开发者面前。
这一现象给开发流程带来的影响虽然不算致命，却也十分恼人。持续存在的报错提示会干扰开发者的视觉判断，在某些情况下甚至可能掩盖真正的配置问题。对于依赖CI/CD自动构建的团队而言，好消息是这类编辑器级别的错误并不会导致流水线失败；但对于在本地环境中一边查看pubspec.yaml、一边编写l10n.yaml的开发者来说，每次打开包含元数据的.arb文件都要面对一片刺眼的红色，这种体验显然谈不上愉悦。
从应对策略来看，目前开发者可以采取的临时方案包括：在VS Code工作区设置中对.arb文件禁用或调整JSON Schema的关联，从而关闭这类误报；或者调整扩展的校验级别，将“错误”降级为“警告”。但这些做法难免会牺牲编辑器对其他JSON语法问题的有效提示，属于一种“为了剪除杂草而连同庄稼一起拔掉”的权宜之计。更根本的解决路径，仍在于等待VS Code相关插件或Flutter官方更新其Schema定义，尽快让编辑器与正式工具链对.arb文件的理解保持一致。
值得一提的是，这并非VS Code与Flutter工具链之间首次出现类似的认知分歧。此前在flutter_localizations生成文件、依赖解析报错等场景中，也曾出现过编辑器提示与实际构建结果不一致的情况。这类问题反复出现，折射出大型开发工具生态中一个难以回避的现实：不同团队维护的多个开发工具，在共享同一文件格式时，往往难以在第一时间做到完全同步。而对普通开发者而言，在工具链之间尚未调和好的“灰色地带”里，保持冷静、以官方命令行工具的实际反馈为准，或许才是最高效的应对之道。