KSP2中PSI变更问题的分析与解决方案

在Kotlin符号处理(KSP)框架的使用过程中，开发者可能会遇到一个常见问题："PSI has changed since creation"错误。这个问题通常出现在SymbolProcessor的finish()方法执行期间，特别是在处理类型和注解时。本文将深入分析这一问题的成因，并介绍KSP团队提供的解决方案。

问题背景

PSI(Program Structure Interface)是IntelliJ平台中用于表示源代码结构的抽象层。在KSP处理过程中，当源代码发生变化时，原有的PSI结构可能不再有效，导致"PSI has changed since creation"错误。

在XProcessing测试用例中，特别是XTypeTest.wildcardWithMissingType场景下，这个问题尤为明显。当KSP执行最后一轮处理时，XProcessing会尝试访问类型和注解信息，而此时PSI可能已经被清理，导致错误发生。

问题根源

问题的核心在于KSP处理流程中的清理时机。在KSP2的早期版本中，清理操作发生在每一轮处理之后，包括最后一轮。这意味着：

1. 第一轮处理完成后立即执行清理
2. 第二轮(最终轮)处理完成后再次执行清理
3. 然后才调用onError或finish方法

这种顺序导致在finish方法中尝试访问PSI结构时，相关资源已经被清理。

解决方案演进

KSP团队在1.0.26版本中对此问题进行了重要改进，调整了处理流程的顺序：

1. 第一轮处理完成后执行清理
2. 第二轮(最终轮)处理
3. 调用onError或finish方法
4. 最后执行清理

这种调整确保了在finish方法执行期间，PSI结构仍然可用。此外，KSP团队还计划在未来版本中引入Processor.finish(resolver: Resolver)和Processor.onError(resolver: Resolver)方法，为开发者提供更明确的API来处理完成和错误情况。

实际影响与迁移建议

对于从KAPT迁移到KSP的开发者，这一变化尤为重要。在KAPT中，开发者习惯在round.isProcessingOver=true时执行最终的检查、汇总或代码生成操作。在KSP1中，这些操作可以放在finish()方法中实现。

对于使用KSP2的开发者，建议：

1. 确保使用1.0.26或更高版本
2. 避免在finish()方法中执行依赖PSI结构的操作
3. 等待未来版本中带有Resolver参数的finish和onError方法发布
4. 目前如有必要，可以通过生成虚拟代码等方式强制触发最后一轮process()调用

总结

KSP框架在不断演进中解决了许多实际开发中的痛点问题。"PSI has changed since creation"错误的解决方案体现了KSP团队对开发者体验的重视。随着新API的引入，KSP将提供更加稳定和灵活的处理流程，帮助开发者更高效地实现代码生成和元编程需求。

对于正在使用或计划迁移到KSP2的开发者，建议关注框架的更新动态，及时调整实现方式，以充分利用框架提供的最新特性。