写 Shell 循环脚本这件事十个新手九个觉得简单。for i in ...; do ...; done一行命令把重复劳动变成自动化成就感直接拉满。但如果你真的把这套思路原封不动搬进生产环境大概率会被线上告警教育得怀疑人生。我见过太多类似的场景课堂作业里用 for 循环批量 ping 了几个 IP考试通过了但到生产环境批量重启服务时脚本跑到一半进程挂掉没有日志、没有断点重启之后不知道处理到哪一步只能对着业务报障发呆。课堂实验关心的是“能不能跑通”生产实践要求的是“能不能跑稳、能不能跑完、出了问题能不能快速恢复”。这个差距就是所有 Shell 脚本“生产改造”的核心矛盾。这篇文章想做的就是把这个“差距”拆开揉碎用一条完整的改造链路讲清楚怎么把一个教科书式的 for 循环脚本改造成可以拿上生产、敢跑通宵、敢面对突发故障的版本。文章适合刚接触 Shell 的运维新人也适合写过一堆脚本但还没“真正上过线”的开发者。我尽量把每一步的“为什么”也讲清楚而不是只给一个“抄作业”的模板。1. 课堂脚本和生产脚本的差别在哪1.1 先从一道课堂练习说起课堂里我们常写的循环脚本大概是这个样子的。假设场景批量检查一组服务器是否在线。#!/bin/bash for ip in $(cat ip_list.txt); do ping -c 1 -W 1 $ip /dev/null if [ $? -eq 0 ]; then echo $ip 在线 else echo $ip 不通 fi done这个脚本教学上是标准答案循环变量、条件判断、退出码检查全都有。但如果这是线上要用的巡检脚本你会发现一堆问题ip_list.txt如果有多余空格或空行$(cat ...)会把内容拆错文件不存在时就相当于循环了一个空列表脚本没有任何报错看似成功实则失败中途断电或被人 CtrlC脚本从头开始跑已处理完的 IP 又被跑了一遍如果 IP 列表有上万条串行 ping 的耗时可以让人等到崩溃没人想看它跑一小时脚本没有日志文件跑完只能盯着屏幕看输出历史结果说没就没。这些不是“写法不好”的问题而是整个设计的目标压根没对上。课堂实验的目标是展示语法生产脚本的目标是输入明确、过程可控、结果可追溯、异常可恢复。目标变了代码自然要像换了一套骨架一样重写。1.2 生产环境最怕什么留活口、断点续跑、失败重试、并发控制生产环境的运维任务本质上是一个“不可重启的批处理”。为什么因为你在凌晨跑一个批量任务等天亮才发现处理到第 357 个文件的时候挂掉了——你不光要修复脚本还要回答一个致命问题前 356 个文件到底成功了没有哪些成功、哪些没成功这说明生产脚本要承担三个层次的职责层次课堂脚本生产脚本执行结果只要命令不报错就行每个迭代成败都要记录中断恢复从头再来断点续跑跳过已完成项失败策略不关心反正整体退出显式决定跳过、重试、还是终止性能串行足够需要并发但要可控另外还有并发问题。几百个文件串行处理可能只需几十分钟但如果是几千个文件、每个都要调远程接口或者做解压压缩串行能把人等到崩溃。生产级脚本要考虑用xargs -P或后台任务 wait的方式做并行但并行又会带来新的问题输出交错、日志混在一起、资源占用不可控。这个平衡很难但必须做。1.3 从“能跑”到“会跑”的心态转换我第一次写生产脚本时也踩过这种坑觉得自己在课堂上学得不错拿到需求就开始写循环写完本地测了一次觉得没报错就上服务器 crontab 挂起来。结果第二天收到监控告警任务跑挂了。我跑到服务器看日志发现脚本的第 23 行报错但脚本是纯串行、只有 echo 没有重定向前面跑了多少步、哪些步失败一概不知。最痛苦的是我想手动补跑但根本没有记录哪些文件已经被处理过了。从那时候起我就养成了一个习惯在动笔之前先闭上眼想——如果这个脚本跑到一半挂了我要怎么知道自己处理到哪了如果我对这个问题没有清晰答案那我写的就不是生产脚本只是把课堂作业挪了位置而已。这种心态转变比记住一百条 Shell 技巧都重要。接下来我讲的改造方法都是建立在这个前提上的脚本不是因为“复杂”所以生产化而是因为“要能回答上面那个问题”才必须生产化。2. 生产改造的核心设计从流程骨架到健壮性2.1 先定输入再写循环参数校验与环境变量拿到改造任务第一件事不是改循环体而是定义“输入是什么”。课堂脚本通常把输入写死在脚本里或者简单地从文件读。生产脚本必须把“谁控制它”这件事想清楚。我通常遵循这些原则输入文件的路径不要写成相对路径要允许通过命令行参数传入或者从环境变量读取。脚本里的目录、并发数、日志路径都尽量参数化。举个例子#!/usr/bin/env bash set -Eeuo pipefail INPUT_FILE${1:-} OUTPUT_DIR${OUTPUT_DIR:-/tmp/output} CONCURRENCY${CONCURRENCY:-4} if [ -z $INPUT_FILE ]; then echo 用法: $0 输入文件路径 2 exit 1 fi if [ ! -f $INPUT_FILE ]; then echo 错误: 输入文件不存在: $INPUT_FILE 2 exit 2 fiset -Eeuo pipefail是生产脚本的标配。很多新手不敢加原因是怕它误伤。我来解释它的每一项-e任何命令返回非零就退出。但要注意在if判断里的命令、while条件里的命令不受影响所以不用太担心。-u未定义变量直接报错避免$VAR拼出空参数导致命令行为诡异。课堂脚本里常见的坑就是变量名拼错结果拼出一个空字符串命令把目录当文件处理。-o pipefail管道命令的最终退出码取所有命令中最右边的非零退出码而不是最后一条命令的退出码。这能防止cmd1 | cmd2中 cmd1 失败但 cmd2 成功导致整体误判成功。-E让 ERR 陷阱对函数和子 shell 生效配合 trap 使用。参数校验要区分“缺失”和“路径不存在”用不同的退出码。退出码不仅表示“有没有成功”还承担了“给调用方传递失败原因”的功能。如果调用方比如 crontab 邮件、监控系统只看退出码至少能区分是参数错还是运行时错。写入临时文件的路径建议用mktemp不要自己拼/tmp/abc_$$。mktemp会保证唯一性和合理权限比手动拼凑安全得多WORK_DIR$(mktemp -d /tmp/process.XXXXXX) trap rm -rf $WORK_DIR EXIT这样即使脚本退出临时目录也会被清掉不会在服务器上留一堆垃圾文件。2.2 循环体的“隔离性”每个迭代独立防串扰Shell 循环里的一个隐蔽问题是变量在循环内被修改后会“污染”下一次迭代。比如你在循环里定义了一个函数、改写了某个全局变量下一次迭代可能莫名其妙地受影响。所以生产级循环脚本里我会刻意让每个迭代尽量独立。几个常见做法循环内的变量都加local或者把循环体的核心逻辑抽成一个函数函数内部变量用local声明process_one() { local file$1 local base base$(basename $file) # ... 处理逻辑 } while IFS read -r line; do process_one $line done $INPUT_FILE使用while read而不是for i in $(cat ...)。这是个老生常谈但非常关键的改造点。for i in $(cat file)有两个先天问题文件里的空格、tab、通配符会被错误拆词当文件特别大时$(cat file)会把整个文件内容吃进内存容易触发参数过长ARG_MAX错误。最稳妥的逐行读取方式while IFS read -r line || [ -n $line ]; do process_one $line done $INPUT_FILE这里|| [ -n $line ]是为了防止文件最后一行没有换行符时漏读。IFS保证行首行尾的空格不被吃掉-r保证反斜杠不会被吞。这些都是课堂不会教但线上一定会踩的细节。尽量避免在循环内修改全局状态。比如要统计成功数、失败数别直接在循环里((count))之后就到处用因为一旦后续加并发管道、subshell统计值可能丢失或错乱。后面讲并发的时候再细说。2.3 日志设计记录每一次迭代的时间、输入、结果生产脚本一定要有自己的日志文件。日志不是给调试用的是给事故恢复用的。我见过太多线上脚本任务失败后没有任何痕迹只能靠业务方猜。我习惯的日志设计很简单LOG_DIR${LOG_DIR:-/var/log/my_script} LOG_FILE${LOG_DIR}/$(basename $0).$(date %Y%m%d).log mkdir -p $LOG_DIR log_info() { echo [$(date %Y-%m-%d %H:%M:%S)] [INFO] $* $LOG_FILE } log_error() { echo [$(date %Y-%m-%d %H:%M:%S)] [ERROR] $* $LOG_FILE }注意几个点日志文件名带上日期方便按天归档如果需要覆盖多天再考虑按小时。在循环里记录每次迭代的输入、结果成功/失败至少写一行。比如if process_one $line; then log_info OK $line else log_error FAIL $line fi日志要追加写入不要覆盖写否则重启一次任务就把之前的日志清空了。别只把 echo 打到 log 21因为 stdout/stderr 混在一起看起来费劲有条件的分类记录更好。如果后面要做“断点续跑”日志里记录的“成功行”甚至可以直接作为续跑的标记来源。2.4 错误处理与退出码set -e 的坑与自救很多人一听说set -e就以为万事大吉。其实set -e在循环里有一些非常坑的行为我踩过好几次这里直接列出来set -e不保证在函数内部、子 shell 内部一定生效。比如管道里的命令失败单看最后一个命令的返回值可能被掩盖。这就是为什么我坚持set -Eeuo pipefail一起用-E和-e配合能扩大 ERR trap 的覆盖范围。set -e突然退出时你可能来不及处理现场。比如临时文件没有清理、后台任务还挂着、日志还来不及写最后一行。解决办法是用trap定义退出时要执行的收尾cleanup() { echo [$(date %Y-%m-%d %H:%M:%S)] 脚本退出开始清理 $LOG_FILE [ -n ${WORK_DIR:-} ] rm -rf $WORK_DIR if [ -n ${BG_PIDS:-} ]; then kill $BG_PIDS 2/dev/null || true fi } trap cleanup EXIT trap echo 收到中断信号; exit 1 INT TERM不要在循环里用set -e后还想着“捕获错误然后继续”。因为一旦某个命令失败整个脚本直接退出预期是“跳过当前项继续处理”的场景会被破坏。正确的做法是要么在循环体内显式判断命令返回值要么把循环体放进一个函数函数内部用|| return处理。例如if command_that_may_fail; then log_info OK $item else log_error FAIL $item跳过 continue fi这是生产脚本最常用、也最不容易出错的模式把“失败”当作一个普通结果由你来决策是继续还是中断。3. 实操把一个 for 循环脚本改造成生产级3.1 原始课堂脚本示例批量压缩日志目录为了讲得更具体我构造一个非常常见的场景每天早上对/logs/目录下前一天的.log文件进行压缩然后删除原文件释放磁盘。这是很多运维同学第一次写生产脚本时会遇到的需求。课堂版长这样#!/bin/bash cd /logs for file in $(ls *.log); do gzip $file done这个到处是坑的“经典作业版”。先列一下问题ls *.log在文件很多时会换行输出文件名带空格或特殊字符时会被拆碎没有参数化哪天要改成压缩 3 天前的文件就得改代码空目录时通配符*.log没匹配到文件ls *.log会直接报错或返回非零然后循环体不执行但脚本没有提示压缩失败没有检测删原文件时才后悔没有日志没有幂等性被定时任务重复执行时会把已压缩过的文件再找一遍虽然.gz后缀不同不会被匹配但逻辑上不够严谨。3.2 改造后的生产级脚本拆解我会把完整脚本写出来然后逐段解释。脚本较长但每一段都对应一个“生产化考量”。#!/usr/bin/env bash # # batch_compress_logs.sh # 批量压缩日志文件支持并发、断点续跑、日志输出 # 用法: ./batch_compress_logs.sh [--days 1] [--dir /logs] # set -Eeuo pipefail # ---------- 参数解析 ---------- DAYS1 LOG_DIR/logs while [ $# -gt 0 ]; do case $1 in --days) DAYS$2 shift 2 ;; --dir) LOG_DIR$2 shift 2 ;; *) echo 未知参数: $1 2 exit 1 ;; esac done # ---------- 参数校验 ---------- if ! [[ $DAYS ~ ^[0-9]$ ]]; then echo 参数 --days 必须是正整数 2 exit 2 fi if [ ! -d $LOG_DIR ]; then echo 日志目录不存在: $LOG_DIR 2 exit 2 fi # ---------- 环境初始化 ---------- SCRIPT_NAME$(basename $0) TIMESTAMP$(date %Y%m%d) LOG_FILE/tmp/${SCRIPT_NAME}.${TIMESTAMP}.log : $LOG_FILE log_info() { echo [$(date %Y-%m-%d %H:%M:%S)] [INFO] $* $LOG_FILE } log_error() { echo [$(date %Y-%m-%d %H:%M:%S)] [ERROR] $* $LOG_FILE } cleanup() { log_info 脚本退出清理完成 } trap cleanup EXIT # ---------- 主体逻辑 ---------- # 找出符合条件且尚未压缩的文件 mapfile -t files (find $LOG_DIR -type f -name *.log -mtime $DAYS -print) if [ ${#files[]} -eq 0 ]; then log_info 没有需要压缩的日志文件 exit 0 fi log_info 共发现 ${#files[]} 个待处理文件开始处理 processed0 failed0 compress_one() { local file$1 local compressed_file${file}.gz if [ -f $compressed_file ]; then log_info SKIP $file (已存在压缩文件) return 0 fi if gzip -c $file $compressed_file; then if rm $file; then log_info OK $file - $compressed_file return 0 else log_error FAIL $file (压缩成功但删除原文件失败) rm -f $compressed_file return 1 fi else log_error FAIL $file (gzip 压缩失败) return 1 fi } # 注意这里用 for 循环 函数保证每个迭代失败后继续处理下一个 for file in ${files[]}; do if compress_one $file; then processed$((processed 1)) else failed$((failed 1)) fi done log_info 处理完成成功 ${processed}失败 ${failed} if [ $failed -gt 0 ]; then exit 3 fi exit 0逐段说明set -Eeuo pipefail放第一行。压制住“脚本死了都不知道死在哪”的情况配合后续退出码至少能把错误暴露出来。参数解析。用while / case支持--days和--dir才具备复用性。别嫌复杂生产环境要用一个脚本处理多种场景全量、增量、指定日期没有参数化就只能复制粘贴脚本那才是维护灾难。参数校验。天数必须是数字目录必须存在。别让脚本在一半时报错越早校验就越早暴露配置问题。日志初始化。LOG_FILE写在/tmp只是示例生产环境建议放到明确的日志目录。: $LOG_FILE是清空/创建文件的小技巧注意这里是为本次运行准备一个全新的日志文件。mapfilefind收集文件列表。这一步替代了for file in $(ls *.log)。mapfile会把 find 输出的每一行存成数组元素天然处理了空格和特殊字符的问题。用find而不是ls的好处是可以精确控制匹配模式、按修改时间过滤、还能用-print0配合mapfile -d 应对极端文件名含换行符。如果要非常稳妥可以改成mapfile -d -t files (find $LOG_DIR -type f -name *.log -mtime $DAYS -print0)幂等性检查。函数开头判断compressed_file是否已存在如果存在就直接跳过。这是“断点续跑”的基础任务中断后重新启动已经压缩成功的文件不会被重复压缩。压缩 删除原文件的原子性问题。先gzip -c $file $compressed_file成功后再删除原文件。这里有两个细节为什么用gzip -c 文件而不是直接gzip $file因为直接gzip默认会在成功后删除原始文件一旦压缩不成功原始文件也可能处于损坏状态。拆成两步先保证压缩产物完整再删除源文件风险隔离更清晰。为什么删除失败要回滚压缩文件因为一个.gz文件产生但原文件还在下次运行会发现compressed_file已存在直接 SKIP就会造成“原文件一直存在压缩文件也一直存在”的假死状态。所以要么删除原文件成功完事要么把压缩文件也删掉让脚本下次能重新压缩。失败计数与退出码。循环体里不set -e中断而是把每个失败记录下来最后根据失败数量决定退出码。生产定时任务crontab通常只关心返回码退出 3 表示“有部分失败”和退出 0 分离开监控系统就能识别。3.3 并发改造xargs -P 与后台任务 wait如果日志文件特别多串行压缩可能太慢。上生产后性能是硬指标。改并发之前要先想清楚我这个任务能并行吗如果每个文件互相不依赖且并发带来的 I/O 压力在可接受范围那就可以。最简单的并发改造是用xargs -P。把循环体抽成脚本或函数后把要处理的文件列表交给 xargsprintf %s\0 ${files[]} | xargs -0 -P $CONCURRENCY -n 1 bash -c file$0 # ... 处理逻辑注意用 log 函数要传入或用 lib 但这里有个麻烦日志输出从函数变成了bash -c函数没法直接复用。所以更推荐“后台任务 wait”的方式pids() for file in ${files[]}; do ( if compress_one $file; then echo OK $file $LOG_FILE else echo FAIL $file $LOG_FILE fi ) pids($!) # 控制并发数量如果后台任务达到上限等其中一个完成 while [ ${#pids[]} -ge $CONCURRENCY ]; do wait -n -p done_pid ${pids[]} 2/dev/null || true # 移除已完成的 pid new_pids() for pid in ${pids[]}; do [ $pid ! $done_pid ] new_pids($pid) done pids(${new_pids[]}) done done wait ${pids[]} 2/dev/null || true这段比较啰嗦其实是 Bash 4.3 的wait -n才能简化。生产环境常常是兼容性要求高的老版本 Bash所以这个“手动移除已结束 PID”的写法虽然笨但通用。并发改造要重点提示并发时的统计变量会丢。原因是括号( ... ) 会开子 shell子 shell 里的processed$((processed1))影响不到父 shell。所以并发模式下统计要用临时文件或echo追加日志不要指望变量计数。3.4 幂等性与断点续跑用标记文件上面脚本里幂等性靠compressed_file是否存在来判断。但很多任务做不到这么天然比如批量修改数据库记录、调用外部接口。这类任务要断点续跑通常用“标记文件”的方式。思路很简单为每个任务项生成一个唯一 ID文件名、行号、记录主键建一个.done目录每完成一项就touch .done/ID循环开始前先检查.done/ID是否存在存在则跳过。示例DONE_DIR${WORK_DIR}/done mkdir -p $DONE_DIR process_one() { local item_id$1 local done_file$DONE_DIR/$item_id if [ -f $done_file ]; then log_info SKIP $item_id return 0 fi # 真正处理逻辑... if 处理成功; then touch $done_file log_info OK $item_id else log_error FAIL $item_id return 1 fi }好处是脚本中断后重跑已经完成的任务被直接 SKIP不会有重复执行的风险也不会因为重复执行产生账单、重复扣量这类生产事故。这里有个细节touch本身也可能失败。如果临时目录满了或者权限不对done 文件没写下但业务逻辑又执行了重跑就会重复处理。所以我一般建议关键任务在业务完成后立刻touch并且touch失败要当作整个任务失败处理宁可让脚本报错也不要留下“逻辑已执行但标记没落盘”的窗口。4. 常见问题与排查技巧实录4.1 循环里变量不生效管道和子 shell 的坑最经典的问题cat file | while read line; do count$((count1)); done; echo $count输出还是 0。原因是在 bash 里管道后面的while是在子 shell 里执行的循环结束后子 shell 退出count的修改没有传回父 shell。解决方式有三个用进程替换while read line; do ... done (cat file)这样while在当前 shell 执行变量能保留。把统计结果写文件最后再读。使用shopt -s lastpipe仅在 bash 4.2 有效。这个选项让管道最后一个命令留在当前 shell但依赖环境。我在生产脚本里最常用的是进程替换它直观、可控而且不需要改动整个流水线。4.2 文件名带空格或特殊字符前面已经提到for file in $(ls *.log)的坑。这里再补充一个更隐蔽的如果文件名是a.b.log和a b.log混在一起并且你用了gzip $file没有加引号脚本能把文件拆成多个参数直接把gzip搞懵。生产并发的调试里这类问题最容易出现“偶发失败”——本地测试时文件名没空格线上有空格就疯狂报错。解决办法凡是变量作为命令参数一律加双引号读取文件列表用while IFS read -r或mapfile匹配文件名用find ... -name *.log -print0。还有处理含换行符的文件名这种极端情况——实测不常见但如果你要写的是那种面向不可信输入的脚本建议升级到-print0read -d 的完全防御式写法。4.3 任务中断后重复执行导致重复操作这个场景可以说是生产事故里最高发的。比如批量发邮件、批量更新库存、批量调支付接口一旦脚本在任务中途因为服务器重启、网络超时而中断运维同学的第一反应往往是“重新跑一遍”。如果脚本没有幂等性设计重跑一遍等于重复发邮件、重复扣款。所以说做任何批量任务前先问自己如果我的脚本被重复执行会发生什么如果答案是“会产生重复操作”那这个脚本后面一定要加一个“幂等机制”——就是上面标记文件、状态记录那套东西。不要觉得“只是个脚本重跑就重跑吧”。线上每一条告警背后都可能有人在替你负重。4.4 超时不处理导致任务卡死循环里调外部命令比如curl、ssh、mysql很容易卡在“连接等待”上。课堂脚本里不考虑超时一跑可能几个小时卡住然后缩进到 Cron 任务里第二天又叠加上一个进程最后机器负载爆炸。生产脚本必须给外部命令加超时。常用办法curl用--connect-timeout 5 --max-time 10任意命令用timeout 30 command args串行循环里给每个 item 加timeout防止单个 item 卡死示例if timeout 30 gzip -c $file $compressed_file; then ... fi4.5 生产环境千万别这样写最后列几条“我强烈不建议在生产写的 Shell 循环”危险写法为什么会出事正确替代for i in $(cat file)空格/换行拆词while read -r或mapfile外部命令不加超时单个 item 卡死整个任务timeout/curl限时参数并发时共享临时文件输出互相覆盖每个子 shell 写独立文件用sleep控制并发不是资源控制拖延进度wait -n/ 信号量忽略退出码语义调用方无法区分错误类型用 0/1/2/3 分类退出另外不要直接对线上目录做cd后动态修改原始文件最好把命令都指向明确路径或用绝对路径。脚本在受限用户下跑时mkdir、touch、写日志都可能失败别在测试时用 root 没感觉上线后才发现全是权限问题。5. 测试、发布与回收脚本上线前的最后一步5.1 先沙箱测试小批量验证改造完不是直接挂 crontab要有一个“沙箱验证”环节。我的习惯是准备一个小测试目录放几十个不同特征的文件空文件、几个 MB 的大文件、文件名带空格的文件、符号链接。用生产脚本对这些文件跑一遍观察日志和结果。然后故意制造一次失败比如把一个文件权限改成000确认脚本能记录失败、跳过、最后返回非零。再模拟中断启动脚本后立刻kill然后重新运行验证幂等逻辑是否生效统计是否准确。最后测试并发参数比如CONCURRENCY2/4/8各跑一次观察是否会资源耗尽。这一套走下来基本能把 90% 的初级问题过滤掉。不要嫌麻烦线上脚本出一次事成本高得多。5.2 发布前的情景区全量、增量、回滚脚本上线前还有一个容易被忽略的点这个脚本到底是一次性任务还是周期性任务如果是周期性任务要考虑两种模式全量模式处理所有历史文件增量模式只处理昨天/当天新增的文件。把参数化做好就能用同一个脚本完成两种模式。比如前面例子里的--days 1就是增量模式--days 3650近似全量。回滚则更重要。很多 Shell 批量操作是不可逆的比如删除原文件后如果压缩文件也损坏数据就没了。生产级设计要问我有没有为每一个破坏性动作留一条“后悔路”现实一点的方案默认不删源文件只压缩到目标目录确认数据没问题后再由另一个清理任务、或者人工命令删除源文件。这样即使压缩产物有问题原始数据还在可以重跑。5.3 脚本也要有生命周期版本、注释、退役最后一个容易被忽略但很重要的生产习惯脚本文件本身要纳入管理。至少做到三点在脚本头部写清楚用途、参数、退出码含义、维护者、创建日期、修改记录。把脚本纳入版本控制不要直接在服务器上手动改完忘了同步导致多台服务器脚本不一致。当脚本要退役或变更行为时先在日志里打点观察一段时间再迁移。我自己在把课堂脚本改成生产脚本的过程中踩过最痛的那次就是没有给删除动作留后悔路。凌晨四点被叫起来发现日志目录全被压缩删了但有一批压缩文件因为磁盘写满损坏了原始文件又没了只能从备份恢复。从那以后我的原则就变成了破坏性动作永远分两步走。写脚本这件事语法上的坑靠背设计上的坑只能靠踩。希望这篇改造思路能让你少踩几个至少在写for或者while的时候多问一句“如果它挂了我能不能知道它走到哪了”。这句话比任何一行命令都值钱。