TypeScript报'string无法索引映射对象'编译错误如何解决

AddonMapping是带固定键的普通对象，合法的键集合仅包含'lf-text'、'lf-image'、'gameflow'，对象本身没有适配任意字符串的动态索引签名。而ContentAddon接口中的alias字段被定义为范围极宽的通用string类型，TypeScript不允许使用范围超出对象合法键集合的字符串去索引对象——传入任意不在映射表内的字符串时，根本取不到对应的模型类，这类风险必须被类型检查拦截。

• 基于AddonMapping自动推导合法的别名联合类型，比手动写字面量更不容易漏维护：

  // 放在 AddonMapping 常量定义后方即可
  type AddonAlias = keyof typeof AddonMapping;
  

• 修正ContentAddon接口的alias字段类型，从根源收窄入参范围，替换原有的通用string类型：

  export interface ContentAddon {
    id: string;
    alias: AddonAlias;
    model: ContentAddonType;
  }
  

• 调整原有校验逻辑，通过类型守卫帮助TypeScript确认索引访问的合法性，替换两处报错的代码：
  调整后的map逻辑完全可通过类型检查，和原有业务逻辑完全一致：

  state.addons = data.addons.map((addon: ContentAddon) => {
    // 保持原有的非法别名抛错逻辑，用in操作符替代原有的undefined判断
    if (!(addon.alias in AddonMapping)) {
      throw new Error(`Unrecognized addon "${addon.alias}"`);
    }
    // 经过上面的类型守卫校验，TS可自动识别该索引访问合法
    const TargetAddonModel = AddonMapping[addon.alias];
    return {
      id: generateUniqueId(),
      alias: addon.alias,
      model: new TargetAddonModel(addon)
    };
  });
  

不要为了消报错直接给AddonMapping添加[key: string]: any形式的动态索引签名，这类写法会完全废掉映射表的类型校验能力，后续传入错误的键名也不会得到类型提示，失去TypeScript的保护意义。如果业务场景实在无法收窄入参的alias类型范围，仅可在确定传入值合法的前提下，用类型断言临时绕开检查作为兜底：

// 临时兜底方案，不建议作为长期实现
const TargetAddonModel = AddonMapping[addon.alias as AddonAlias];

内容的提问来源于stack exchange，提问作者envy