iOS App能否编程删除Application Support目录下的数据？

核心结论 #

默认情况下每次启动直接删除该目录内容是不安全的操作，不建议直接这么做

目录本质说明 #

_EXTERNAL_DATA是Core Data框架自动生成的专属目录：当你在Core Data模型中为二进制类型的属性开启Allows External Storage选项时，系统不会把大体积的二进制内容存入sqlite数据库文件，而是单独写入该目录，数据库中仅保留指向对应文件的引用关联。
你清理Kingfisher缓存不生效的原因也在这里：你项目里的部分大体积资源（大概率是图片、业务附件类内容）是通过Core Data做持久化存储的，没有走Kingfisher的缓存目录。

为什么你测试删除后没有出现问题 #

如果删除后测试阶段App运行正常，说明该目录下存储的全部是可从服务端重新拉取的缓存类数据，没有用户本地生成的不可复现的持久化数据（比如未上传的用户草稿、本地自定义配置等），但这仅代表你的特定业务场景下删除不会触发严重故障，不代表操作本身符合苹果的设计规范。

风险点说明 #

• 如果后续你在Core Data中新增了需要持久化的二进制属性并开启了外部存储，直接删目录会直接导致用户本地数据丢失，且无法恢复
• 直接删除目录可能会导致正在运行的Core Data事务读取不到关联的二进制文件，触发数据库不一致崩溃
• 每次启动全删会导致所有缓存内容需要重新拉取，额外消耗用户流量，降低App冷启动后的加载速度

推荐的优化方案 #

• 第一步先溯源：遍历你项目中所有Core Data模型的二进制属性，确认哪些开启了Allows External Storage，明确对应属性的业务属性，区分是可丢弃的缓存数据还是必须保留的用户数据
• 缓存类数据不要直接删目录：通过Core Data的正常CRUD接口删除过期、无用的实体记录，系统会自动同步删除_EXTERNAL_DATA目录下对应的关联文件，不会产生孤儿文件占用空间
• 如果确认所有该目录下的内容都是可清理的缓存，建议增加清理触发条件：比如App存储占用超过你设定的阈值、用户主动点击清理缓存按钮、或者App退到后台闲时清理，不要每次启动都执行删除操作

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