先记住这个答案
GraphQL破坏性变更指客户端不修改查询就无法正常获取预期数据的改动。典型包括：删除字段/类型/Enum值，重命名字段，将可空改为非空，修改参数、输入字段或返回类型（如Int转String），以及调整参数默认值。规避的核心是“先加后弃”：先新增兼容字段或类型，配合@deprecated引导迁移，待旧流量消除后再移除。类型系统演进不依赖版本号，而是通过可组合的schema修改维持向后兼容。
- 删除、重命名必然破坏；非空收缩仅在可能 null 时破坏
- 先添加新字段，弃用旧字段再移除
- 用@deprecated引导客户端迁移
破坏性变更的类型系统机制
GraphQL schema是强类型契约，客户端通过内省或代码生成获得静态类型。任何使现有查询在解析阶段失败或在执行阶段返回不同结构的改动都是破坏性的。例如删除字段，旧查询引用它立即报错；修改字段返回类型，如Int改成String，响应JSON的数值变为字符串，客户端类型假设被打破。
非空标记变化尤其微妙：将String改为String!，如果服务端对某些记录返回null，整个字段错误，使部分数据可达性下降。反过来String!改为String也可能给客户端带来风险，因为非空字段的客户端通常不做null处理，一旦服务端返回null可能导致运行时异常，因此通常也应视为潜在破坏性变更。另一个破坏点是给已有字段增加必填参数，因为旧查询没传该参数会报错。
从username到name的重命名迁移
假设某社交App有User类型，字段username被客户端广泛用于显示昵称。产品决定改名name并改用更宽松的显示规则。若直接删除username并添加name，所有旧查询立即损坏。采用分阶段：先在User上增加name: String，将username标记@deprecated(reason: "Use name")，同时变更resolver使两字段返回相同数据。
等待客户端更新周期（如4个版本后）监控内省或查询日志确认username使用率趋零，再在下一个大版本移除username。期间若新客户端直接使用name没问题，旧客户端仍能工作，只是收到弃用警告。此策略将破坏性拆成两个非破坏性步骤：添加字段是安全的，弃用不影响执行，最终移除是在旧流量消失后。若无法确定净使用量，可保留弃用字段更久。
何时无法完全避免破坏
某些场景不存在向后兼容的临时方案。例如修复一个字段返回错误类型，如用户自建对象暴露了内部ID串，想改成结构化对象，但JSON形状完全不同。即使添加新字段，旧字段也必须保留数据，若旧数据无法精确映射或保留旧字段带来安全隐患，就不得不破坏。
另一个边界是共享schema多方使用，你控制的客户端可以协调，但第三方无法强制升级。这时选择破坏性变更需通过版本化端点（如不同路径承载不同schema）或使用schema federation隔离影响。代价是多份schema维护成本，或增加查询复杂度限制来避免旧客户端滥用。破坏性变更并非禁止，而是需要评估影响面和迁移成本，通常早期API可以容忍破坏，进入稳定期后用弃用周期管理。
容易答错的地方
- 类型拓宽不会破坏
- 把
Int改成String看起来响应更灵活，但客户端生成的类型从number变为string，运行时会失败，同时序列化方式变化，属于破坏性变更。任何改变响应JSON的类型对应关系都是破坏。 - 删参数不是破坏
- 删除一个可选参数，旧查询若传了该变量，GraphQL会报错"Unknown argument"，因为参数定义不存在了，因此即使参数是可选的，删除它也会破坏现有查询。需要保留参数并忽略（deprecate），或先增加替代。
面试官还会怎么问？
如何自动检测schema演进中的破坏性变更？
可用graphql-inspector等工具对比前后schema。它识别删除字段、类型变化、参数增删等，但不理解语义。判断非空收缩是否破坏取决于数据源是否可能返回null，需人工结合业务。
@deprecated指令会使字段失效吗？
不会。@deprecated仅提供弃用理由，客户端仍可查询，服务端照常执行。它只是提醒开发者，不产生运行时影响，因此废弃是安全的。
schema版本号和演进式变更矛盾吗？
官方推荐演进而非版本号，因为版本号导致多重schema和客户端碎片。但私有API或无法控制客户端时可使用版本作为最后手段，成本是维护多套schema。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。