企业官网建设流程全解析

做iOS开发的人，多多少少都被“描述文件”和“lock文件”折磨过。尤其是团队协作、多环境打包、证书来回切换的时候，~/Library/MobileDevice/Provisioning Profiles/下面堆了几百个.mobileprovision，Xcode每次签名都像在抽奖；另一边，.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: hsc=200 ec=-22410，这类问题里，本地描述文件状态混乱确实是常见的推手之一。旧描述文件不会自己删除，新下载的描述文件又经常是相同的App ID，Xcode一多就晕了。

更坑的是描述文件没法靠肉眼判断优劣，文件名是一串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或者Linux，Bash无需任何第三方运行时，系统自带，而且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 主要清理对象和路径规划

动手写脚本前，我先把要清理的对象列成了一张表，这样思路非常清晰：

值得注意的是，并不是所有*.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_NAME="skill" readonly VERSION="1.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_DAYS=0 CLEAN_PROFILES=true CLEAN_LOCKS=true DRY_RUN=false FORCE=false

这里有几点解释一下。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_clean=0 local kept=0 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，里面包含<key>ExpirationDate</key><date>2027-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_count=0 local skip_count=0 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 skip=false for keep_name in "${EXCLUDE_LOCKS[@]}"; do if [ "$base" = "$keep_name" ]; then skip=true 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_LOCKS=false shift ;; --locks) CLEAN_PROFILES=false shift ;; --days) KEEP_DAYS="$2" shift 2 ;; --dry-run) DRY_RUN=true shift ;; --force) FORCE=true 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_RUN=false clean_profiles DRY_RUN=false clean_locks log "skill $VERSION done" } main "$@"

调试过程中我发现一个隐蔽的问题：如果函数内部用全局变量DRY_RUN来区分模式，第一遍扫描已经用remove_file删了文件，第二遍“真正执行”时文件没了，日志看起来会像“删了又删”。所以上面这个主流程里，我把第一遍完全当作“预检扫描”，只输出统计信息，不实际删除；确认和清除DRY_RUN标志之后才真正执行第二遍。简单处理也就是直接运行一次带DRY_RUN=false的清理，因为第一次没有删任何文件，第二次才真正动手。实际跑的时候，建议第一次始终带--dry-run观察输出，确认无误后再执行不带该参数的命令。

3.6 安装与别名配置

脚本保存为skill.sh后，需要加执行权限，并在PATH里放一个软链，这样就能当系统命令一样在任意目录执行：

chmod +x ~/dotfiles/skill.sh ln -s ~/dotfiles/skill.sh /usr/local/bin/skill skill --help

如果你用的是zsh（macOS默认shell），也可以直接在~/.zshrc里加别名，指向脚本路径：

alias skill="$HOME/dotfiles/skill.sh"

4. 实操：命令行跑skill解决真实开发场景

4.1 场景一：iOS签名失败，描述文件问题

某次真机调试，Xcode直接报签名失败: 描述文件申请失败: get xcodetoken err srp_setp1 err: hsc=200 ec=-22410，一下把我看懵了。这类报错有时候是Apple后台授权问题，但更多时候和本机描述文件、Xcode缓存状态有关。我的放心操作路径是：

1. 先skill --dry-run --profiles看看本机有多少过期描述文件；
2. skill --profiles清理过期描述文件；
3. 重启Xcode，重新进入Signing & Capabilities页面，手动选择刚下载的最新描述文件；
4. 如果还有问题，检查系统时间是否准确、开发者账号是否需要重新登录。

实测中，清理掉一堆过期且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.lock

error: 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 2>&1

注意定时任务尽量不要加--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.lockfile，Go项目可能有go.sum，这些都要提前讨论清楚；
• 默认保持--dry-run风格，甚至可以在脚本里设置“连续跑三次dry-run才允许正式执行”的强制机制，对刚接手脚本的同事来说会友好很多。

我在实际使用中最满意的一点，是它把“清理描述文件”和“清理lock文件”两个原本割裂的维护行为统一成了一个命令。敲下去之前你不知道本机有多少垃圾，敲完之后看到扫描统计和日志，心里特别有数。这类工具本身不复杂，但遇到的每个人几乎都经历了同样的坑，把这些坑沉淀在脚本里，就不用每次叹息“怎么又被锁卡住了”。

最后再分享一个小技巧：不管写的是清理脚本还是自动化工具，第一次上线永远先跑--dry-run，看着输出清单确认三遍再真正执行。我见过有同事在清理脚本里写错了路径变量，差点把整个项目目录删掉的情况，那真是“删库跑路”级别的灾难。工具越顺手，越要敬畏它背后的rm。