Swift中结构体使用协议类型属性时报不遵循Decodable/Encodable协议错误

你遇到的 Codable 遵循报错，本质是 Swift 类型系统的限制导致的：

• Codable 的自动合成逻辑要求所有存储属性必须是确定的具体类型，不能直接把「遵循某协议的抽象类型」作为存储属性——编译器没法预判实际运行时这个位置存的是 LabelConfig 还是 ButtonConfig，自然生成不出对应属性的解码/编码代码，直接报不遵循协议的错。
• 哪怕让 UIConfig 协议本身继承 Codable，也解决不了问题：协议只是类型约束，没有具体的存储实现，自动合成的编解码逻辑找不到对应的具体类型入口，和你各个子类有没有实现 Codable 没有直接关联。

结合你现有代码里已经有 objectid 字段标识组件类型的业务逻辑，不需要额外改 JSON 结构，按下面的步骤调整就能跑通：

• 给所有配置子类明确实现 Codable 协议
  你现有的 LabelConfig、ButtonConfig、InputConfig 都是引用类型，需要显式声明遵守 Codable，别依赖编译器的隐式合成，避免类继承场景下的合成逻辑漏写。示例参考：

  // 保留原协议的类型约束即可，不需要在协议上叠加 Codable 继承
  protocol UIConfig: AnyObject {
      var bgColor: String? { get set }
  }
  
  class LabelConfig: UIConfig, Codable {
      var bgColor: String?
      var label: String? = ""
  }
  
  class ButtonConfig: UIConfig, Codable {
      var bgColor: String?
      var btn_label: String = ""
  }
  

  注：类的 Codable 实现如果字段都是基础类型，只要显式声明遵守 Codable，编译器可以自动生成符合要求的编解码方法，不需要手写全流程的 init(from:) 和 encode(to:)，除非有自定义字段。

• 给 ScreenData 手动实现 Codable，绑定类型分支逻辑
  这步是解决动态类型解码的核心：手动重写解码/编码方法，用已经有的 objectid 字段作为分支判断依据，决定 config 字段该解码成哪个具体类型，示例实现如下：

  struct ScreenData: Codable {
      var id: String
      var objectid: String
      var config: UIConfig
  
      enum CodingKeys: String, CodingKey {
          case id, objectid, config
      }
  
      // 自定义解码逻辑
      init(from decoder: Decoder) throws {
          let container = try decoder.container(keyedBy: CodingKeys.self)
          id = try container.decode(String.self, forKey: .id)
          objectid = try container.decode(String.self, forKey: .objectid)
          // 按组件ID匹配对应的配置类型解码
          switch objectid {
          case "bd_label":
              config = try container.decode(LabelConfig.self, forKey: .config)
          case "bd_button":
              config = try container.decode(ButtonConfig.self, forKey: .config)
          case "bd_input":
              config = try container.decode(InputConfig.self, forKey: .config)
          default:
              throw DecodingError.dataCorruptedError(
                  forKey: .objectid,
                  in: container,
                  debugDescription: "未识别的组件类型：\(objectid)"
              )
          }
      }
  
      // 自定义编码逻辑
      func encode(to encoder: Encoder) throws {
          var container = encoder.container(keyedBy: CodingKeys.self)
          try container.encode(id, forKey: .id)
          try container.encode(objectid, forKey: .objectid)
          // 按实际的配置类型匹配对应的编码逻辑
          switch config {
          case let labelConfig as LabelConfig:
              try container.encode(labelConfig, forKey: .config)
          case let buttonConfig as ButtonConfig:
              try container.encode(buttonConfig, forKey: .config)
          case let inputConfig as InputConfig:
              try container.encode(inputConfig, forKey: .config)
          default:
              throw EncodingError.invalidValue(
                  config,
                  EncodingError.Context(
                      codingPath: container.codingPath,
                      debugDescription: "未识别的配置类型，无法完成编码"
                  )
              )
          }
      }
  }
  

• 调整完上面的逻辑后，原来 loadScreenView 方法里的强制 as! 类型转换已经是安全的——因为解码阶段就已经把 config 转成了对应类型，不会再出现类型不匹配的运行时崩溃。
• 不需要额外在 JSON 里加类型标识字段，完全可以复用现有的 objectid 做分支判断，减少冗余数据。
• Swift 目前不支持抽象协议类型直接参与自动 Codable 合成，所有带动态类型分支的解码/编码场景，必须通过手动实现分支逻辑完成。

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