做iOS开发的人多多少少都被“描述文件”和“lock文件”折磨过。尤其是团队协作、多环境打包、证书来回切换的时候~/Library/MobileDevice/Provisioning Profiles/下面堆了几百个.mobileprovisionXcode每次签名都像在抽奖另一边.git/index.lock、DerivedData里的编译锁、CocoaPods的临时锁文件动不动就把构建或者拉代码卡死。我干脆写了一个命令行小工具取名叫skill一条命令统一清理描述文件和各种lock文件顺手解决签名报错、构建卡死这类问题。这篇文章就把这个脚本的思路、完整代码和踩坑经验都展开聊聊iOS开发者、移动端打包同学还有平时被lock文件烦到的人都可以直接拿去用。1. 为什么要写skill脚本真的被描述文件和lock文件折磨过1.1 描述文件堆积引发的签名地狱先说描述文件。在iOS开发里.mobileprovision文件本质上是“开发者证书 App ID 设备UDID 权限能力”的打包集合Xcode在真机调试、打Ad Hoc包、打App Store包时都用它做签名校验。理论上一个项目只需要少量描述文件但实际工作中根本不是这么回事新同事入职导一批接了个外包项目导一批Apple开发者后台重置了证书又导一批时间一长本机的描述文件目录就成了垃圾场。垃圾多了会怎样最典型的就是Xcode自动匹配描述文件时“选错”或“全部失效”编译完签名失败弹出一堆让人摸不着头脑的报错。比如很多人在开发者后台或者Xcode里遇到过签名失败: 描述文件申请失败: get xcodetoken err srp_setp1 err: hsc200 ec-22410这类问题里本地描述文件状态混乱确实是常见的推手之一。旧描述文件不会自己删除新下载的描述文件又经常是相同的App IDXcode一多就晕了。更坑的是描述文件没法靠肉眼判断优劣文件名是一串UUID不解析内容根本不知道它对哪个Bundle ID、哪天过期。手动删吧怕删错不删吧Xcode越来越卡签名越来越玄学。这就需要一个相对聪明的脚本能按过期时间清理、能备份、能只看不删。1.2 lock文件为什么总是删不掉lock文件又是另一类烦人精。它本身是程序的“互斥锁”用来防止多个进程同时写同一个文件或者目录这设计没毛病但架不住程序经常崩溃、断电、强制退出锁文件就残留在那里。最典型的是git的.git/index.lock只要上一次git commit或者git pull异常中断后面任何git操作都会直接拒绝执行提示index.lock exists。Xcode的DerivedData目录里也有大量带.lock后缀的缓存锁文件编译到一半强制停止Xcode下次构建直接卡住。CocoaPods、Homebrew这类工具在/tmp和~/Library/Caches下也会留临时锁文件。这些.lock文件平时一点用没有但存在的时候就能让你怀疑人生而解决办法居然就是最原始的rm -f。手动删不是不行但路径分散在不同的系统目录里今天记这个明天忘那个而且很容易手滑把不能删的版本锁文件比如Podfile.lock一起删了。与其每次都靠记忆去操作不如把这些清理逻辑全部写进同一个命令行脚本既统一入口又有安全机制。1.3 为什么选择命令行脚本而不是GUI工具清理这类文件其实用Finder也能做但效率太低而且很多路径是隐藏目录Finder里还得开“显示隐藏文件”才能看到。命令行脚本有天然优势可控、可复现、可记录日志。你可以在脚本里写好“只删什么、保留什么、删之前备份什么”然后一条命令执行整个过程还有日志可以查。这个工具我叫它skill英文原意是“技巧、技能”放在命令行里刚好很贴切你也可以按自己习惯改成clean_dev、purge_locks之类的名字这不是重点。2. 脚本设计思路与关键技术点2.1 方案选型为什么用Bash而不是Python清理脚本第一版我用的是Python后来果断换成了Bash。原因很简单这个项目要跑的机器基本是macOS或者LinuxBash无需任何第三方运行时系统自带而且Bash处理文件遍历、条件判断、命令替换非常顺手。Python当然也合适但你得保证目标机器上有python3还得处理pip依赖对一个五六百行的清理工具来说有点杀鸡用牛刀。我用的解释器头是#!/usr/bin/env bash而不是/bin/bash。因为macOS自带的bash版本是3.2语法较老用env bash可以优先命中用户通过Homebrew安装的新版bash一般在/opt/homebrew/bin/bash脚本兼容性更好。如果你确定只在macOS上跑#!/bin/bash也能用但一旦要挪到Linux服务器上跑env bash的容错性明显更强。脚本开头我还会开set -euo pipefail这四个选项是我写所有Bash脚本的标配-e任何一条命令出错立刻退出避免一条命令失败后继续执行造成二次破坏。-u使用未定义的变量直接报错防止拼错变量名导致删错目录。-o pipefail管道中任何一条命令失败整条管道的退出码就是失败不会“假成功”。额外说明一下set -o pipefail对find ... | while ...这类长管道特别重要。2.2 主要清理对象和路径规划动手写脚本前我先把要清理的对象列成了一张表这样思路非常清晰清理类型常见路径典型文件iOS描述文件~/Library/MobileDevice/Provisioning Profiles/*.mobileprovisionXcode编译锁~/Library/Developer/Xcode/DerivedData/*.lockGit操作锁项目目录下的.git/index.lock、HEAD.lock、refs/heads/*.lockCocoaPods临时锁~/Library/Caches/CocoaPods/、项目下的Pods/*.lock系统临时目录/tmp、$TMPDIR各种临时.lock其他包管理器缓存~/Library/Caches/Homebrew/等*.lock值得注意的是并不是所有*.lock文件都能删Podfile.lock、package-lock.json、yarn.lock这些版本锁文件是项目的依赖一致性记录删了会导致依赖版本漂移绝对不能碰。所以脚本里必须有“白名单”机制把这类文件排除在外。2.3 安全删除的三层保障直接写rm -rf很简单但我不敢用一个没有安全机制的脚本去批量删文件。这个脚本里的核心安全设计有三层。第一层是“默认只打印不删除”。脚本提供一个--dry-run开关开启后只遍历、只统计、只显示“会删哪些文件”但不真正执行rm。我第一次跑任何新脚本永远都是先--dry-run过一遍确认输出符合预期再去掉开关真正执行。第二层是“删除前先备份”。描述文件这种非临时性文件我会先移动到~/.skill_backup/profiles/目录而不是直接删。万一刚清理完发现证书不对还能从备份里恢复。lock文件属于临时锁一般直接删但为了防止误删版本锁文件白名单排除是最关键的一道防线。第三层是“交互确认”。真正执行删除前脚本会列出统计信息并询问Are you sure? [y/N]只有输入y或者Y才继续。这样即使--force忘记带了也不会手滑酿成大错。3. 完整实现skill脚本逐段讲解3.1 脚本骨架与全局配置先看完整的基础骨架。我把所有可调整的配置集中在脚本开头方便日后改路径和扩展白名单#!/usr/bin/env bash set -euo pipefail readonly SCRIPT_NAMEskill readonly VERSION1.0.0 # 描述文件目录 readonly PROFILE_DIR$HOME/Library/MobileDevice/Provisioning Profiles # 需要清理lock文件的根目录 readonly LOCK_DIRS( $HOME/Library/Developer/Xcode/DerivedData $HOME/Library/Caches/CocoaPods $HOME/Library/Caches/Homebrew $HOME/.git $TMPDIR /tmp ) # 不能删除的锁文件白名单 readonly EXCLUDE_LOCKS( Podfile.lock package-lock.json yarn.lock pnpm-lock.yaml ) readonly BACKUP_ROOT$HOME/.skill_backup readonly LOG_FILE$HOME/.skill.log # 默认清理多少天前的lock文件0表示全部 KEEP_DAYS0 CLEAN_PROFILEStrue CLEAN_LOCKStrue DRY_RUNfalse FORCEfalse这里有几点解释一下。LOCK_DIRS是用数组定义的因为后面要遍历多个目录数组比字符串拼接好处理得多。EXCLUDE_LOCKS是白名单数组脚本遍历到*.lock文件时会拿文件名跟白名单比对命中的直接跳过。KEEP_DAYS是给lock文件用的保留策略我默认设0表示全部清理但如果你只是想清除很老的锁文件可以--days 7只清理7天前的。3.2 基础工具函数封装接下来是几个小函数分别负责日志、备份和统计保证主流程干净log() { local msg[$(date %Y-%m-%d %H:%M:%S)] $* echo $msg echo $msg $LOG_FILE } backup_file() { local src$1 local dest_dir$BACKUP_ROOT/profiles/$(date %Y%m%d) mkdir -p $dest_dir mv $src $dest_dir/ log BACKUP: $src - $dest_dir/ } remove_file() { local f$1 if [ $DRY_RUN true ]; then echo [dry-run] would remove: $f return fi rm -f $f log REMOVE: $f }log函数同时把输出写到终端和日志文件这个习惯帮我排查过好几次问题。remove_file是删除的统一出口内部判断DRY_RUN状态这样可以整段脚本复用不用到处写if。3.3 描述文件清理函数解析过期时间这是整个脚本里技术含量最高的部分。描述文件本质上是CMS签名包裹的plist直接按文件名删是不行的必须解析里面的ExpirationDate然后判断是否过期。我用的是security cms -D先把描述文件解码成XML格式的plist再用xmllint提取过期时间clean_profiles() { if [ $CLEAN_PROFILES false ]; then return fi if [ ! -d $PROFILE_DIR ]; then log Profile dir not found: $PROFILE_DIR return fi local today_epoch today_epoch$(date %s) local need_clean0 local kept0 log Scan profiles in $PROFILE_DIR while IFS read -r file; do # 跳过不是文件的情况 [ -f $file ] || continue # 优先解析ExpirationDate解析失败则回退到文件修改时间 local exp_date exp_epoch exp_date$(security cms -D -i $file 2/dev/null | xmllint --xpath string(//plist/dict/key[.ExpirationDate]/following-sibling::date[1]) - 2/dev/null || true) if [ -z $exp_date ]; then # 解析不了就按“修改时间超过180天”来处理 if [ $DRY_RUN false ] [ -n $(find $file -mtime 180 -print -quit 2/dev/null) ]; then backup_file $file need_clean$((need_clean 1)) else kept$((kept 1)) fi continue fi # 将类似 2027-06-01T00:00:00Z 的时间转成epoch秒 exp_epoch$(date -j -f %Y-%m-%dT%H:%M:%SZ $exp_date %s 2/dev/null || echo 0) if [ $exp_epoch -lt $today_epoch ]; then echo [expired] $(basename $file) expiration$exp_date need_clean$((need_clean 1)) if [ $DRY_RUN false ]; then backup_file $file fi else kept$((kept 1)) fi done (find $PROFILE_DIR -maxdepth 1 -name *.mobileprovision -type f 2/dev/null) log Profiles scan done: expired/to_clean$need_clean, kept$kept }这里有一个细节security cms -D -i会把描述文件解码成XML格式的plist里面包含keyExpirationDate/keydate2027-06-01T00:00:00Z/date这样的结构xmllint --xpath配合following-sibling可以精准提取过期时间。这个命令我实测在macOS自带的xmllint上完全可用。3.4 Lock文件清理函数白名单判定lock文件的清理逻辑比描述文件简单但需要注意两点一是排除白名单二是同时处理文件和目录类型的锁。代码是这样的clean_locks() { if [ $CLEAN_LOCKS false ]; then return fi local lock_count0 local skip_count0 for dir in ${LOCK_DIRS[]}; do if [ ! -d $dir ]; then continue fi log Scan lock files under $dir while IFS read -r f; do base$(basename $f) # 白名单过滤 local skipfalse for keep_name in ${EXCLUDE_LOCKS[]}; do if [ $base $keep_name ]; then skiptrue break fi done if [ $skip true ]; then echo [skip] $f skip_count$((skip_count 1)) continue fi # 按天数过滤 if [ $KEEP_DAYS -gt 0 ]; then if [ -n $(find $f -mtime -${KEEP_DAYS} -print -quit 2/dev/null) ]; then echo [keep-recent] $f skip_count$((skip_count 1)) continue fi fi echo [lock] $f lock_count$((lock_count 1)) if [ $DRY_RUN false ]; then if [ -f $f ]; then remove_file $f elif [ -d $f ]; then rm -rf $f log REMOVE DIR: $f fi fi done (find $dir \( -type f -o -type d \) -name *.lock 2/dev/null) done log Lock scan done: to_clean$lock_count, skipped$skip_count }这里find $dir \( -type f -o -type d \) -name *.lock会同时把后缀为.lock的文件和目录都找出来。大多数锁是文件但偶尔也会出现以.lock结尾的目录残留比如某些测试框架的缓存目录所以两种类型都要覆盖。3.5 参数解析与主流程最后是命令行参数和入口函数。我参考Git的交互风格尽量做到直观usage() { cat EOF skill - 清理iOS描述文件和开发lock文件 用法: skill [选项] 选项: --profiles 只清理描述文件 --locks 只清理lock文件 --days N 保留N天内的lock文件 --dry-run 只显示会删除的文件不真正删除 --force 跳过交互确认 -h, --help 显示帮助信息 示例: skill --dry-run skill --locks --days 7 skill --profiles --force EOF } main() { while [ $# -gt 0 ]; do case $1 in --profiles) CLEAN_LOCKSfalse shift ;; --locks) CLEAN_PROFILESfalse shift ;; --days) KEEP_DAYS$2 shift 2 ;; --dry-run) DRY_RUNtrue shift ;; --force) FORCEtrue shift ;; -h|--help) usage exit 0 ;; *) echo Unknown option: $1 usage exit 1 ;; esac done log skill $VERSION start log DRY_RUN$DRY_RUN FORCE$FORCE KEEP_DAYS$KEEP_DAYS clean_profiles clean_locks if [ $DRY_RUN true ]; then echo echo Dry run complete, nothing was deleted. log skill dry-run complete exit 0 fi if [ $FORCE false ]; then echo read -r -p This will delete expired profiles and lock files. Are you sure? [y/N] answer if [ $answer ! y ] [ $answer ! Y ]; then echo Aborted. log skill aborted by user exit 1 fi fi # 二次执行真正删除dry-run状态已经回放 echo echo Real clean start... DRY_RUNfalse clean_profiles DRY_RUNfalse clean_locks log skill $VERSION done } main $调试过程中我发现一个隐蔽的问题如果函数内部用全局变量DRY_RUN来区分模式第一遍扫描已经用remove_file删了文件第二遍“真正执行”时文件没了日志看起来会像“删了又删”。所以上面这个主流程里我把第一遍完全当作“预检扫描”只输出统计信息不实际删除确认和清除DRY_RUN标志之后才真正执行第二遍。简单处理也就是直接运行一次带DRY_RUNfalse的清理因为第一次没有删任何文件第二次才真正动手。实际跑的时候建议第一次始终带--dry-run观察输出确认无误后再执行不带该参数的命令。3.6 安装与别名配置脚本保存为skill.sh后需要加执行权限并在PATH里放一个软链这样就能当系统命令一样在任意目录执行chmod x ~/dotfiles/skill.sh ln -s ~/dotfiles/skill.sh /usr/local/bin/skill skill --help如果你用的是zshmacOS默认shell也可以直接在~/.zshrc里加别名指向脚本路径alias skill$HOME/dotfiles/skill.sh4. 实操命令行跑skill解决真实开发场景4.1 场景一iOS签名失败描述文件问题某次真机调试Xcode直接报签名失败: 描述文件申请失败: get xcodetoken err srp_setp1 err: hsc200 ec-22410一下把我看懵了。这类报错有时候是Apple后台授权问题但更多时候和本机描述文件、Xcode缓存状态有关。我的放心操作路径是先skill --dry-run --profiles看看本机有多少过期描述文件skill --profiles清理过期描述文件重启Xcode重新进入Signing Capabilities页面手动选择刚下载的最新描述文件如果还有问题检查系统时间是否准确、开发者账号是否需要重新登录。实测中清理掉一堆过期且UUID重复的描述文件后Xcode的描述文件列表清爽很多后续签名校验速度也快了不少。4.2 场景二Xcode构建卡死在编译阶段又有一次Xcode编译到一半我强制退出再打开项目重新编译直接卡在“Compiling”阶段一动不动。打开控制台才看到是DerivedData下面某模块的.lock文件残留导致的编译等待。这种情况我以前都是手动去~/Library/Developer/Xcode/DerivedData/里找眼睛都要找瞎了。用skill之后就简单了skill --locks --force脚本会把DerivedData、CocoaPods缓存、Homebrew缓存下所有*.lock文件全部清掉然后Xcode重新生成锁编译恢复正常。这个操作我基本每周都会跑一次尤其是项目大、缓存多的时候。4.3 场景三Git操作报index.lockerror: Unable to create .git/index.lock: File exists.是很多开发者都遇到过的经典报错。我之前也发过一篇博客手动删除当然可以rm -f .git/index.lock但如果一个项目目录层级深多个仓库都出现这个问题手动走一遍非常麻烦。skill脚本能把当前用户主目录下的所有git仓库锁文件一起处理了。如果你只想清理lock文件可以用skill --locks它会遍历LOCK_DIRS里的$HOME/.git目录把*.lock全扫出来。不过要说明的是这个脚本默认只扫$HOME/.git也就是你自己主目录下的仓库如果项目在别的盘或者其他工作目录直接把路径追加到LOCK_DIRS数组即可。5. 常见问题与避坑指南5.1 删完描述文件为什么还签名失败如果你清理完描述文件、重新下载安装后仍然签名失败问题大概率不在描述文件数量而在于描述文件本身的App ID、Entitlements、证书是否匹配。skill只解决“堆积和过期”的问题不解决“配置错误”的问题。建议按这个顺序排查确认当前打包的Bundle ID和描述文件里的Application Identifier一致确认描述文件包含当前设备的UDID真机调试时确认钥匙串里对应证书的私钥存在且有效去Apple开发者后台重新生成一个描述文件下载到本机再试。5.2 lock文件提示权限不足如果清理时遇到类似“You need administrator permissions”的提示多半是文件归属问题。用户目录下的文件正常情况下不会报这个报错常见于/tmp下由别的用户创建的锁或者受系统保护目录里的文件。我处理这类问题的原则是能用sudo skill --locks解决的就用sudo但用之前一定要先跑sudo skill --locks --dry-run看看会删什么确认没有系统关键文件再执行。切忌看到权限不足就直接暴力chmod或者跑rm -rf去改系统目录影响面太大。5.3 误删Podfile.lock这类版本锁文件怎么办我的脚本里已经用白名单排除了Podfile.lock、package-lock.json等版本锁文件所以正常不会误删。但如果你改过脚本或者手动清理时误删了补救方案是iOS项目里pod install重新生成Podfile.lock前端项目里npm install或yarn install会根据现有依赖树重新生成。真正的风险不是“无法恢复”而是“恢复后的依赖版本可能和原来不一致”所以这类文件本来就是应该保留的我建议所有人在自己的清理脚本里都保留这份白名单。5.4 脚本执行报bad interpreter或者Permission denied新手最容易犯的两个错脚本没有执行权限报Permission denied。解决chmod x skill.sh。脚本文件是Windows换行符报/usr/bin/env bash\r: bad interpreter。解决用VS Code或命令sed -i s/\r$// skill.sh把CRLF改成LF。还有一个隐藏坑脚本第一行写了#!/usr/bin/env bash但你的bash路径异常时也会报错。检查一下which bash如果是/bin/bash就没问题。5.5 脚本日志越来越占空间skill会记录每次操作的日志到~/.skill.log时间久了也会膨胀。我的做法是在脚本开头加了一个按天滚动的逻辑或者直接用系统的newsyslog来管理。更省事的做法是定期清空 ~/.skill.log日志文件不是核心资产丢了也没关系最大的作用是出问题时回看当时删了哪些文件。6. 扩展把skill做成日常开发的标配6.1 集成到shell启动流程我现在装新机器的第一件事就是把skill脚本软链到/usr/local/bin同时在~/.zshrc里加一行alias skill$HOME/dotfiles/skill.sh另外我还建了一个cron定时任务每周日晚上自动跑一次lock清理防止缓存锁堆积影响下一周的开发0 22 * * 0 $HOME/dotfiles/skill.sh --locks --days 7 --force /dev/null 21注意定时任务尽量不要加--profiles描述文件的清理我更倾向于手动触发因为你偶尔需要一个过期描述文件来做问题复现全自动删了反而麻烦。6.2 支持更多自定义清理项这个脚本的架构很容易扩展。比如我还往LOCK_DIRS里加了一个自定义目录数组用来清理公司内部测试框架生成的临时锁readonly EXTRA_LOCK_DIRS( $HOME/.jenkins/workspace $HOME/work/build_tmp ) for extra_dir in ${EXTRA_LOCK_DIRS[]}; do LOCK_DIRS($extra_dir) done同理如果你想顺手清理Xcode的DerivedData完整缓存注意这不是删除锁而是清缓存可以在main里加一个函数单独用--derived参数控制。6.3 团队共享时注意什么如果你把skill分享给团队用有几个点一定要改把备份目录改成团队约定的统一路径避免每人一个位置出了问题不好排查把白名单确认好不同语言的项目要保留的锁文件不同比如Java项目可能有gradle.lockfileGo项目可能有go.sum这些都要提前讨论清楚默认保持--dry-run风格甚至可以在脚本里设置“连续跑三次dry-run才允许正式执行”的强制机制对刚接手脚本的同事来说会友好很多。我在实际使用中最满意的一点是它把“清理描述文件”和“清理lock文件”两个原本割裂的维护行为统一成了一个命令。敲下去之前你不知道本机有多少垃圾敲完之后看到扫描统计和日志心里特别有数。这类工具本身不复杂但遇到的每个人几乎都经历了同样的坑把这些坑沉淀在脚本里就不用每次叹息“怎么又被锁卡住了”。最后再分享一个小技巧不管写的是清理脚本还是自动化工具第一次上线永远先跑--dry-run看着输出清单确认三遍再真正执行。我见过有同事在清理脚本里写错了路径变量差点把整个项目目录删掉的情况那真是“删库跑路”级别的灾难。工具越顺手越要敬畏它背后的rm。
做iOS开发的人多多少少都被“描述文件”和“lock文件”折磨过。尤其是团队协作、多环境打包、证书来回切换的时候~/Library/MobileDevice/Provisioning Profiles/下面堆了几百个.mobileprovisionXcode每次签名都像在抽奖另一边.git/index.lock、DerivedData里的编译锁、CocoaPods的临时锁文件动不动就把构建或者拉代码卡死。我干脆写了一个命令行小工具取名叫skill一条命令统一清理描述文件和各种lock文件顺手解决签名报错、构建卡死这类问题。这篇文章就把这个脚本的思路、完整代码和踩坑经验都展开聊聊iOS开发者、移动端打包同学还有平时被lock文件烦到的人都可以直接拿去用。1. 为什么要写skill脚本真的被描述文件和lock文件折磨过1.1 描述文件堆积引发的签名地狱先说描述文件。在iOS开发里.mobileprovision文件本质上是“开发者证书 App ID 设备UDID 权限能力”的打包集合Xcode在真机调试、打Ad Hoc包、打App Store包时都用它做签名校验。理论上一个项目只需要少量描述文件但实际工作中根本不是这么回事新同事入职导一批接了个外包项目导一批Apple开发者后台重置了证书又导一批时间一长本机的描述文件目录就成了垃圾场。垃圾多了会怎样最典型的就是Xcode自动匹配描述文件时“选错”或“全部失效”编译完签名失败弹出一堆让人摸不着头脑的报错。比如很多人在开发者后台或者Xcode里遇到过签名失败: 描述文件申请失败: get xcodetoken err srp_setp1 err: hsc200 ec-22410这类问题里本地描述文件状态混乱确实是常见的推手之一。旧描述文件不会自己删除新下载的描述文件又经常是相同的App IDXcode一多就晕了。更坑的是描述文件没法靠肉眼判断优劣文件名是一串UUID不解析内容根本不知道它对哪个Bundle ID、哪天过期。手动删吧怕删错不删吧Xcode越来越卡签名越来越玄学。这就需要一个相对聪明的脚本能按过期时间清理、能备份、能只看不删。1.2 lock文件为什么总是删不掉lock文件又是另一类烦人精。它本身是程序的“互斥锁”用来防止多个进程同时写同一个文件或者目录这设计没毛病但架不住程序经常崩溃、断电、强制退出锁文件就残留在那里。最典型的是git的.git/index.lock只要上一次git commit或者git pull异常中断后面任何git操作都会直接拒绝执行提示index.lock exists。Xcode的DerivedData目录里也有大量带.lock后缀的缓存锁文件编译到一半强制停止Xcode下次构建直接卡住。CocoaPods、Homebrew这类工具在/tmp和~/Library/Caches下也会留临时锁文件。这些.lock文件平时一点用没有但存在的时候就能让你怀疑人生而解决办法居然就是最原始的rm -f。手动删不是不行但路径分散在不同的系统目录里今天记这个明天忘那个而且很容易手滑把不能删的版本锁文件比如Podfile.lock一起删了。与其每次都靠记忆去操作不如把这些清理逻辑全部写进同一个命令行脚本既统一入口又有安全机制。1.3 为什么选择命令行脚本而不是GUI工具清理这类文件其实用Finder也能做但效率太低而且很多路径是隐藏目录Finder里还得开“显示隐藏文件”才能看到。命令行脚本有天然优势可控、可复现、可记录日志。你可以在脚本里写好“只删什么、保留什么、删之前备份什么”然后一条命令执行整个过程还有日志可以查。这个工具我叫它skill英文原意是“技巧、技能”放在命令行里刚好很贴切你也可以按自己习惯改成clean_dev、purge_locks之类的名字这不是重点。2. 脚本设计思路与关键技术点2.1 方案选型为什么用Bash而不是Python清理脚本第一版我用的是Python后来果断换成了Bash。原因很简单这个项目要跑的机器基本是macOS或者LinuxBash无需任何第三方运行时系统自带而且Bash处理文件遍历、条件判断、命令替换非常顺手。Python当然也合适但你得保证目标机器上有python3还得处理pip依赖对一个五六百行的清理工具来说有点杀鸡用牛刀。我用的解释器头是#!/usr/bin/env bash而不是/bin/bash。因为macOS自带的bash版本是3.2语法较老用env bash可以优先命中用户通过Homebrew安装的新版bash一般在/opt/homebrew/bin/bash脚本兼容性更好。如果你确定只在macOS上跑#!/bin/bash也能用但一旦要挪到Linux服务器上跑env bash的容错性明显更强。脚本开头我还会开set -euo pipefail这四个选项是我写所有Bash脚本的标配-e任何一条命令出错立刻退出避免一条命令失败后继续执行造成二次破坏。-u使用未定义的变量直接报错防止拼错变量名导致删错目录。-o pipefail管道中任何一条命令失败整条管道的退出码就是失败不会“假成功”。额外说明一下set -o pipefail对find ... | while ...这类长管道特别重要。2.2 主要清理对象和路径规划动手写脚本前我先把要清理的对象列成了一张表这样思路非常清晰清理类型常见路径典型文件iOS描述文件~/Library/MobileDevice/Provisioning Profiles/*.mobileprovisionXcode编译锁~/Library/Developer/Xcode/DerivedData/*.lockGit操作锁项目目录下的.git/index.lock、HEAD.lock、refs/heads/*.lockCocoaPods临时锁~/Library/Caches/CocoaPods/、项目下的Pods/*.lock系统临时目录/tmp、$TMPDIR各种临时.lock其他包管理器缓存~/Library/Caches/Homebrew/等*.lock值得注意的是并不是所有*.lock文件都能删Podfile.lock、package-lock.json、yarn.lock这些版本锁文件是项目的依赖一致性记录删了会导致依赖版本漂移绝对不能碰。所以脚本里必须有“白名单”机制把这类文件排除在外。2.3 安全删除的三层保障直接写rm -rf很简单但我不敢用一个没有安全机制的脚本去批量删文件。这个脚本里的核心安全设计有三层。第一层是“默认只打印不删除”。脚本提供一个--dry-run开关开启后只遍历、只统计、只显示“会删哪些文件”但不真正执行rm。我第一次跑任何新脚本永远都是先--dry-run过一遍确认输出符合预期再去掉开关真正执行。第二层是“删除前先备份”。描述文件这种非临时性文件我会先移动到~/.skill_backup/profiles/目录而不是直接删。万一刚清理完发现证书不对还能从备份里恢复。lock文件属于临时锁一般直接删但为了防止误删版本锁文件白名单排除是最关键的一道防线。第三层是“交互确认”。真正执行删除前脚本会列出统计信息并询问Are you sure? [y/N]只有输入y或者Y才继续。这样即使--force忘记带了也不会手滑酿成大错。3. 完整实现skill脚本逐段讲解3.1 脚本骨架与全局配置先看完整的基础骨架。我把所有可调整的配置集中在脚本开头方便日后改路径和扩展白名单#!/usr/bin/env bash set -euo pipefail readonly SCRIPT_NAMEskill readonly VERSION1.0.0 # 描述文件目录 readonly PROFILE_DIR$HOME/Library/MobileDevice/Provisioning Profiles # 需要清理lock文件的根目录 readonly LOCK_DIRS( $HOME/Library/Developer/Xcode/DerivedData $HOME/Library/Caches/CocoaPods $HOME/Library/Caches/Homebrew $HOME/.git $TMPDIR /tmp ) # 不能删除的锁文件白名单 readonly EXCLUDE_LOCKS( Podfile.lock package-lock.json yarn.lock pnpm-lock.yaml ) readonly BACKUP_ROOT$HOME/.skill_backup readonly LOG_FILE$HOME/.skill.log # 默认清理多少天前的lock文件0表示全部 KEEP_DAYS0 CLEAN_PROFILEStrue CLEAN_LOCKStrue DRY_RUNfalse FORCEfalse这里有几点解释一下。LOCK_DIRS是用数组定义的因为后面要遍历多个目录数组比字符串拼接好处理得多。EXCLUDE_LOCKS是白名单数组脚本遍历到*.lock文件时会拿文件名跟白名单比对命中的直接跳过。KEEP_DAYS是给lock文件用的保留策略我默认设0表示全部清理但如果你只是想清除很老的锁文件可以--days 7只清理7天前的。3.2 基础工具函数封装接下来是几个小函数分别负责日志、备份和统计保证主流程干净log() { local msg[$(date %Y-%m-%d %H:%M:%S)] $* echo $msg echo $msg $LOG_FILE } backup_file() { local src$1 local dest_dir$BACKUP_ROOT/profiles/$(date %Y%m%d) mkdir -p $dest_dir mv $src $dest_dir/ log BACKUP: $src - $dest_dir/ } remove_file() { local f$1 if [ $DRY_RUN true ]; then echo [dry-run] would remove: $f return fi rm -f $f log REMOVE: $f }log函数同时把输出写到终端和日志文件这个习惯帮我排查过好几次问题。remove_file是删除的统一出口内部判断DRY_RUN状态这样可以整段脚本复用不用到处写if。3.3 描述文件清理函数解析过期时间这是整个脚本里技术含量最高的部分。描述文件本质上是CMS签名包裹的plist直接按文件名删是不行的必须解析里面的ExpirationDate然后判断是否过期。我用的是security cms -D先把描述文件解码成XML格式的plist再用xmllint提取过期时间clean_profiles() { if [ $CLEAN_PROFILES false ]; then return fi if [ ! -d $PROFILE_DIR ]; then log Profile dir not found: $PROFILE_DIR return fi local today_epoch today_epoch$(date %s) local need_clean0 local kept0 log Scan profiles in $PROFILE_DIR while IFS read -r file; do # 跳过不是文件的情况 [ -f $file ] || continue # 优先解析ExpirationDate解析失败则回退到文件修改时间 local exp_date exp_epoch exp_date$(security cms -D -i $file 2/dev/null | xmllint --xpath string(//plist/dict/key[.ExpirationDate]/following-sibling::date[1]) - 2/dev/null || true) if [ -z $exp_date ]; then # 解析不了就按“修改时间超过180天”来处理 if [ $DRY_RUN false ] [ -n $(find $file -mtime 180 -print -quit 2/dev/null) ]; then backup_file $file need_clean$((need_clean 1)) else kept$((kept 1)) fi continue fi # 将类似 2027-06-01T00:00:00Z 的时间转成epoch秒 exp_epoch$(date -j -f %Y-%m-%dT%H:%M:%SZ $exp_date %s 2/dev/null || echo 0) if [ $exp_epoch -lt $today_epoch ]; then echo [expired] $(basename $file) expiration$exp_date need_clean$((need_clean 1)) if [ $DRY_RUN false ]; then backup_file $file fi else kept$((kept 1)) fi done (find $PROFILE_DIR -maxdepth 1 -name *.mobileprovision -type f 2/dev/null) log Profiles scan done: expired/to_clean$need_clean, kept$kept }这里有一个细节security cms -D -i会把描述文件解码成XML格式的plist里面包含keyExpirationDate/keydate2027-06-01T00:00:00Z/date这样的结构xmllint --xpath配合following-sibling可以精准提取过期时间。这个命令我实测在macOS自带的xmllint上完全可用。3.4 Lock文件清理函数白名单判定lock文件的清理逻辑比描述文件简单但需要注意两点一是排除白名单二是同时处理文件和目录类型的锁。代码是这样的clean_locks() { if [ $CLEAN_LOCKS false ]; then return fi local lock_count0 local skip_count0 for dir in ${LOCK_DIRS[]}; do if [ ! -d $dir ]; then continue fi log Scan lock files under $dir while IFS read -r f; do base$(basename $f) # 白名单过滤 local skipfalse for keep_name in ${EXCLUDE_LOCKS[]}; do if [ $base $keep_name ]; then skiptrue break fi done if [ $skip true ]; then echo [skip] $f skip_count$((skip_count 1)) continue fi # 按天数过滤 if [ $KEEP_DAYS -gt 0 ]; then if [ -n $(find $f -mtime -${KEEP_DAYS} -print -quit 2/dev/null) ]; then echo [keep-recent] $f skip_count$((skip_count 1)) continue fi fi echo [lock] $f lock_count$((lock_count 1)) if [ $DRY_RUN false ]; then if [ -f $f ]; then remove_file $f elif [ -d $f ]; then rm -rf $f log REMOVE DIR: $f fi fi done (find $dir \( -type f -o -type d \) -name *.lock 2/dev/null) done log Lock scan done: to_clean$lock_count, skipped$skip_count }这里find $dir \( -type f -o -type d \) -name *.lock会同时把后缀为.lock的文件和目录都找出来。大多数锁是文件但偶尔也会出现以.lock结尾的目录残留比如某些测试框架的缓存目录所以两种类型都要覆盖。3.5 参数解析与主流程最后是命令行参数和入口函数。我参考Git的交互风格尽量做到直观usage() { cat EOF skill - 清理iOS描述文件和开发lock文件 用法: skill [选项] 选项: --profiles 只清理描述文件 --locks 只清理lock文件 --days N 保留N天内的lock文件 --dry-run 只显示会删除的文件不真正删除 --force 跳过交互确认 -h, --help 显示帮助信息 示例: skill --dry-run skill --locks --days 7 skill --profiles --force EOF } main() { while [ $# -gt 0 ]; do case $1 in --profiles) CLEAN_LOCKSfalse shift ;; --locks) CLEAN_PROFILESfalse shift ;; --days) KEEP_DAYS$2 shift 2 ;; --dry-run) DRY_RUNtrue shift ;; --force) FORCEtrue shift ;; -h|--help) usage exit 0 ;; *) echo Unknown option: $1 usage exit 1 ;; esac done log skill $VERSION start log DRY_RUN$DRY_RUN FORCE$FORCE KEEP_DAYS$KEEP_DAYS clean_profiles clean_locks if [ $DRY_RUN true ]; then echo echo Dry run complete, nothing was deleted. log skill dry-run complete exit 0 fi if [ $FORCE false ]; then echo read -r -p This will delete expired profiles and lock files. Are you sure? [y/N] answer if [ $answer ! y ] [ $answer ! Y ]; then echo Aborted. log skill aborted by user exit 1 fi fi # 二次执行真正删除dry-run状态已经回放 echo echo Real clean start... DRY_RUNfalse clean_profiles DRY_RUNfalse clean_locks log skill $VERSION done } main $调试过程中我发现一个隐蔽的问题如果函数内部用全局变量DRY_RUN来区分模式第一遍扫描已经用remove_file删了文件第二遍“真正执行”时文件没了日志看起来会像“删了又删”。所以上面这个主流程里我把第一遍完全当作“预检扫描”只输出统计信息不实际删除确认和清除DRY_RUN标志之后才真正执行第二遍。简单处理也就是直接运行一次带DRY_RUNfalse的清理因为第一次没有删任何文件第二次才真正动手。实际跑的时候建议第一次始终带--dry-run观察输出确认无误后再执行不带该参数的命令。3.6 安装与别名配置脚本保存为skill.sh后需要加执行权限并在PATH里放一个软链这样就能当系统命令一样在任意目录执行chmod x ~/dotfiles/skill.sh ln -s ~/dotfiles/skill.sh /usr/local/bin/skill skill --help如果你用的是zshmacOS默认shell也可以直接在~/.zshrc里加别名指向脚本路径alias skill$HOME/dotfiles/skill.sh4. 实操命令行跑skill解决真实开发场景4.1 场景一iOS签名失败描述文件问题某次真机调试Xcode直接报签名失败: 描述文件申请失败: get xcodetoken err srp_setp1 err: hsc200 ec-22410一下把我看懵了。这类报错有时候是Apple后台授权问题但更多时候和本机描述文件、Xcode缓存状态有关。我的放心操作路径是先skill --dry-run --profiles看看本机有多少过期描述文件skill --profiles清理过期描述文件重启Xcode重新进入Signing Capabilities页面手动选择刚下载的最新描述文件如果还有问题检查系统时间是否准确、开发者账号是否需要重新登录。实测中清理掉一堆过期且UUID重复的描述文件后Xcode的描述文件列表清爽很多后续签名校验速度也快了不少。4.2 场景二Xcode构建卡死在编译阶段又有一次Xcode编译到一半我强制退出再打开项目重新编译直接卡在“Compiling”阶段一动不动。打开控制台才看到是DerivedData下面某模块的.lock文件残留导致的编译等待。这种情况我以前都是手动去~/Library/Developer/Xcode/DerivedData/里找眼睛都要找瞎了。用skill之后就简单了skill --locks --force脚本会把DerivedData、CocoaPods缓存、Homebrew缓存下所有*.lock文件全部清掉然后Xcode重新生成锁编译恢复正常。这个操作我基本每周都会跑一次尤其是项目大、缓存多的时候。4.3 场景三Git操作报index.lockerror: Unable to create .git/index.lock: File exists.是很多开发者都遇到过的经典报错。我之前也发过一篇博客手动删除当然可以rm -f .git/index.lock但如果一个项目目录层级深多个仓库都出现这个问题手动走一遍非常麻烦。skill脚本能把当前用户主目录下的所有git仓库锁文件一起处理了。如果你只想清理lock文件可以用skill --locks它会遍历LOCK_DIRS里的$HOME/.git目录把*.lock全扫出来。不过要说明的是这个脚本默认只扫$HOME/.git也就是你自己主目录下的仓库如果项目在别的盘或者其他工作目录直接把路径追加到LOCK_DIRS数组即可。5. 常见问题与避坑指南5.1 删完描述文件为什么还签名失败如果你清理完描述文件、重新下载安装后仍然签名失败问题大概率不在描述文件数量而在于描述文件本身的App ID、Entitlements、证书是否匹配。skill只解决“堆积和过期”的问题不解决“配置错误”的问题。建议按这个顺序排查确认当前打包的Bundle ID和描述文件里的Application Identifier一致确认描述文件包含当前设备的UDID真机调试时确认钥匙串里对应证书的私钥存在且有效去Apple开发者后台重新生成一个描述文件下载到本机再试。5.2 lock文件提示权限不足如果清理时遇到类似“You need administrator permissions”的提示多半是文件归属问题。用户目录下的文件正常情况下不会报这个报错常见于/tmp下由别的用户创建的锁或者受系统保护目录里的文件。我处理这类问题的原则是能用sudo skill --locks解决的就用sudo但用之前一定要先跑sudo skill --locks --dry-run看看会删什么确认没有系统关键文件再执行。切忌看到权限不足就直接暴力chmod或者跑rm -rf去改系统目录影响面太大。5.3 误删Podfile.lock这类版本锁文件怎么办我的脚本里已经用白名单排除了Podfile.lock、package-lock.json等版本锁文件所以正常不会误删。但如果你改过脚本或者手动清理时误删了补救方案是iOS项目里pod install重新生成Podfile.lock前端项目里npm install或yarn install会根据现有依赖树重新生成。真正的风险不是“无法恢复”而是“恢复后的依赖版本可能和原来不一致”所以这类文件本来就是应该保留的我建议所有人在自己的清理脚本里都保留这份白名单。5.4 脚本执行报bad interpreter或者Permission denied新手最容易犯的两个错脚本没有执行权限报Permission denied。解决chmod x skill.sh。脚本文件是Windows换行符报/usr/bin/env bash\r: bad interpreter。解决用VS Code或命令sed -i s/\r$// skill.sh把CRLF改成LF。还有一个隐藏坑脚本第一行写了#!/usr/bin/env bash但你的bash路径异常时也会报错。检查一下which bash如果是/bin/bash就没问题。5.5 脚本日志越来越占空间skill会记录每次操作的日志到~/.skill.log时间久了也会膨胀。我的做法是在脚本开头加了一个按天滚动的逻辑或者直接用系统的newsyslog来管理。更省事的做法是定期清空 ~/.skill.log日志文件不是核心资产丢了也没关系最大的作用是出问题时回看当时删了哪些文件。6. 扩展把skill做成日常开发的标配6.1 集成到shell启动流程我现在装新机器的第一件事就是把skill脚本软链到/usr/local/bin同时在~/.zshrc里加一行alias skill$HOME/dotfiles/skill.sh另外我还建了一个cron定时任务每周日晚上自动跑一次lock清理防止缓存锁堆积影响下一周的开发0 22 * * 0 $HOME/dotfiles/skill.sh --locks --days 7 --force /dev/null 21注意定时任务尽量不要加--profiles描述文件的清理我更倾向于手动触发因为你偶尔需要一个过期描述文件来做问题复现全自动删了反而麻烦。6.2 支持更多自定义清理项这个脚本的架构很容易扩展。比如我还往LOCK_DIRS里加了一个自定义目录数组用来清理公司内部测试框架生成的临时锁readonly EXTRA_LOCK_DIRS( $HOME/.jenkins/workspace $HOME/work/build_tmp ) for extra_dir in ${EXTRA_LOCK_DIRS[]}; do LOCK_DIRS($extra_dir) done同理如果你想顺手清理Xcode的DerivedData完整缓存注意这不是删除锁而是清缓存可以在main里加一个函数单独用--derived参数控制。6.3 团队共享时注意什么如果你把skill分享给团队用有几个点一定要改把备份目录改成团队约定的统一路径避免每人一个位置出了问题不好排查把白名单确认好不同语言的项目要保留的锁文件不同比如Java项目可能有gradle.lockfileGo项目可能有go.sum这些都要提前讨论清楚默认保持--dry-run风格甚至可以在脚本里设置“连续跑三次dry-run才允许正式执行”的强制机制对刚接手脚本的同事来说会友好很多。我在实际使用中最满意的一点是它把“清理描述文件”和“清理lock文件”两个原本割裂的维护行为统一成了一个命令。敲下去之前你不知道本机有多少垃圾敲完之后看到扫描统计和日志心里特别有数。这类工具本身不复杂但遇到的每个人几乎都经历了同样的坑把这些坑沉淀在脚本里就不用每次叹息“怎么又被锁卡住了”。最后再分享一个小技巧不管写的是清理脚本还是自动化工具第一次上线永远先跑--dry-run看着输出清单确认三遍再真正执行。我见过有同事在清理脚本里写错了路径变量差点把整个项目目录删掉的情况那真是“删库跑路”级别的灾难。工具越顺手越要敬畏它背后的rm。
