簡介匯總279個可直接投入使用的Shell腳本應用集覆蓋DDoS攻擊IP自動屏蔽、Linux系統(tǒng)郵件告警、MySQL數(shù)據(jù)庫單/多循環(huán)備份、Nginx訪問日志按天切割與深度分析、網(wǎng)卡實時流量監(jiān)控等高頻運維場景。腳本邏輯清晰、關鍵命令注釋完整適合Linux/Unix系統(tǒng)管理員、運維工程師及希望提升自動化能力的初中級學習者參考可結合實際業(yè)務需求修改后部署。資源包內(nèi)共1個PDF文檔體積4.69MB便于快速瀏覽、檢索與離線學習當前已有154人學習下載。內(nèi)容不僅有現(xiàn)成腳本代碼還梳理了日期獲取、日志分析、iptables策略、mysqldump備份、cron定時任務等核心技術點幫助讀者理解腳本背后的設計思路與排錯途徑。對于需要快速構建服務器安全防護、數(shù)據(jù)庫災備和日志管理體系的團隊這份資料具備較高實用價值。1. 279個開箱即用的shell腳本治好的是“重復勞動”焦慮不是“復雜問題”執(zhí)念第一次拿到“279個開箱即用的shell腳本”壓縮包時我的第一反應是“這么多八成有擺設”。翻完關鍵腳本后發(fā)現(xiàn)它的價值不在單個腳本多聰明而在于把巡檢、日志、備份、網(wǎng)絡檢查這些最高頻的運維場景統(tǒng)一成可以直接跑的形態(tài)。2024年新版腳本風格更干凈變量、函數(shù)、退出碼的約定更一致這對批量投入使用的人來說反而最值錢。這套東西適合日常維護幾十臺服務器的運維、剛接手機器又不想從零養(yǎng)腳本庫的開發(fā)者也適合交付時快速湊齊基礎檢查項的人。它解決的是重復勞動不是復雜問題。下面按“怎么落地、怎么選、怎么改、坑在哪”的順序把這套腳本真正用起來。2. 壓縮包到手怎么落地目錄規(guī)劃、環(huán)境準備和首次運行拿到279個腳本的壓縮包之后第一件要做的事不是立刻翻代碼而是先把目錄結構立起來。腳本集合最大的隱患就是目錄亂腳本放在頂層、配置文件散落各處、日志不知道寫到哪里一旦跑起來根本沒法維護。我一般會首先在服務器上建一個獨立目錄比如~/ops/shell-lib把整個集合按“可執(zhí)行腳本、公共函數(shù)、配置文件、日志、備份產(chǎn)物”拆成五塊。2.1 拿到手先定位先看目錄樹和說明文檔先把壓縮包解開然后用tree -L 2看結構第一時間確定三件事腳本是不是按功能分子目錄了、有沒有公共函數(shù)文件、有沒有內(nèi)置的說明文檔。很多腳本集合表面有279個文件實際有效腳本只有兩百多剩下的是配置文件、空目錄、說明文檔甚至有幾個是同一個腳本的舊版本。mkdir -p ~/ops/shell-lib cd ~/ops/shell-lib # 解壓指令要和你實際拿到的包名一致 tar xzf shell-scripts-2024.tar.gz # 看兩層目錄先摸清結構再動手 find . -maxdepth 2 -type f | head -50這段代碼的作用是先把環(huán)境立起來。mkdir -p保證目錄不存在時自動創(chuàng)建后面所有腳本都能在這個公共目錄里啟動。find加上maxdepth 2是為了先看前兩層避免一次性輸出太多文件反而看不清結構。解壓之后我建議把包里的說明文檔先翻一遍重點看作者聲明的依賴項、Linux發(fā)行版兼容性、有沒有說明默認安裝路徑這些信息比腳本本身更能決定你能不能在一小時內(nèi)跑通。2.2 環(huán)境準備先確認本地有沒有這些默認依賴279個腳本不可能都只用原生的bash。凡是涉及網(wǎng)絡、磁盤、數(shù)據(jù)庫、文本處理的腳本多少都會依賴外部命令最常見的是curl、grep、awk、sed、gzip、df、mysqldump、jq。跑全套之前我建議先做一次依賴盤點缺什么補什么避免腳本跑到一半才報“command not found”。# 一鍵檢查常用依賴是否存在 for cmd in bash curl grep awk sed gzip df jq mysql mysqldump bc getopt; do if command -v $cmd /dev/null 21; then echo [OK] $cmd else echo [MISSING] $cmd fi done這段代碼的意義不是挨個執(zhí)行which而是用command -v做一次快速掃描。command -v返回0表示命令存在非0表示缺失比which更可靠因為which在某些精簡系統(tǒng)里本身可能就不存在。輸出里凡是出現(xiàn)[MISSING]的就是你在跑對應腳本之前必須先處理的。比如jq缺失JSON解析類的腳本就跑不了mysql缺失數(shù)據(jù)庫備份腳本就會在執(zhí)行時直接退出。2.3 把 bin 目錄加進 PATH讓腳本可以被直接調(diào)用不把腳本加進 PATH 的后果是你每次都要bash /完整/路徑/腳本.sh這非常累而且腳本里的人相對路徑一旦寫錯就會翻車。常見做法是在~/.bashrc里增加環(huán)境變量把腳本的核心目錄固定下來再把可執(zhí)行腳本所在的 bin 目錄加進 PATH。cat ~/.bashrc EOF # shell腳本庫環(huán)境變量 export OPS_HOME$HOME/ops/shell-lib export OPS_CONF$OPS_HOME/conf export OPS_LOG$OPS_HOME/logs export PATH$OPS_HOME/bin:$PATH EOF source ~/.bashrc # 驗證是否能直接找到腳本 command -v disk_check || echo 還沒找到檢查 PATH 配置這里用EOF而不是EOF是有意的帶引號的 EOF 能防止$HOME、$OPS_HOME在追加時被展開確保變量是寫進文件里、而不是寫成固定的當前目錄值。source之后新開的終端也會生效。PATH 加在靠前位置是防止系統(tǒng)里同名命令覆蓋腳本庫。2.4 跑通第一個腳本先選一個副作用最小的腳本驗證環(huán)境想驗證整個環(huán)境是否正常最快的辦法是跑一個只讀類腳本比如磁盤空間檢查或系統(tǒng)信息收集腳本。這種腳本沒有刪除操作、不寫外部文件跑掛了也不影響系統(tǒng)。以磁盤檢查腳本為例你只需要傳一個閾值參數(shù)進去# 閾值設成90意思就是超過90%才告警 bash bin/disk_check.sh 90 echo 退出碼$?跑完你會發(fā)現(xiàn)腳本輸出可能只有一行也可能有格式化表格更重要的是退出碼。很多腳本都會約定0為正常、非0為異常。在第一次跑通之后我建議你觀察一下它的輸出格式是純文本、還是帶顏色、還是能輸出 CSV。這一步看起來不起眼但后面你要接告警或自動化平臺時輸出格式?jīng)Q定了你要不要加一層解析。3. 279個腳本按場景怎么選巡檢、日志、備份、網(wǎng)絡四類先看哪幾個腳本集合一多最容易犯的錯是把時間花在“把所有腳本都讀一遍”上。我的建議是反過來先確定你自己手頭最痛的場景再按場景去翻對應腳本。絕大多數(shù)合集里的腳本都能歸到四類系統(tǒng)巡檢、日志處理、數(shù)據(jù)庫備份、網(wǎng)絡連通性檢查。每一類的考察重點不一樣下面分別說。3.1 系統(tǒng)巡檢類先看指標采集范圍再看輸出格式系統(tǒng)巡檢類腳本通常是這個合集里數(shù)量最多的一類涵蓋CPU負載、內(nèi)存占用、磁盤容量、進程數(shù)、登錄失敗次數(shù)等等。挑選時我只看兩點第一是指標采集是否用對了命令第二是結果是否結構化。# 一個典型的巡檢腳本骨架采集磁盤使用率并輸出 CSV #!/usr/bin/env bash set -Eeuo pipefail echo filesystem,use_percent,mount_point df -h | awk NR1 { gsub(%, , $5); print $1,$5,$6 }這段代碼展示了巡檢腳本的通用套路。set -Eeuo pipefail讓腳本在遇到未定義變量、管道失敗時立刻退出避免錯誤被吞掉。df -h輸出第一行是標題NR1跳過標題行gsub把百分比后面的%去掉最后拼成CSV。你拿到巡檢腳本時重點看有沒有類似的“可解析輸出”設計。如果一個巡檢腳本只是打印一堆字符串沒有分隔符那它更適合人看不適合接自動化平臺。3.2 日志處理類切割、歸檔、統(tǒng)計三件事邊界條件完全不一樣日志腳本在279個集合理通常也占不小比例。按天切割是最常見的需求。挑日志腳本時要特別留意三件事文件名后綴怎么生成、是否跳過正在寫的內(nèi)容、保留天數(shù)由什么參數(shù)控制。# 日志切割腳本按天歸檔并按保留天數(shù)清理舊日志 #!/usr/bin/env bash set -Eeuo pipefail LOG_DIR${1:-/var/log/myapp} KEEP_DAYS${2:-7} if [ ! -d $LOG_DIR ]; then echo [ERROR] 目錄不存在: $LOG_DIR 2 exit 2 fi # 將 *.log 原地壓縮為 *.log.20240101.gz find $LOG_DIR -maxdepth 1 -type f -name *.log -print0 | while IFS read -r -d f; do gzip -S .$(date %Y%m%d).gz $f done # 找到超過保留天數(shù)的 .gz 文件并刪除 find $LOG_DIR -maxdepth 1 -type f -name *.gz -mtime $KEEP_DAYS -delete這段代碼把切割和清理分成兩步。參數(shù)化設計讓路徑和保留天數(shù)可以在調(diào)用時傳${1:-默認值}的寫法保證不傳參也不會直接報錯。-print0配合read -r -d 是為了處理文件名里有空格的情況這一步在日志目錄里特別重要很多日志文件名都帶空格或特殊字符。gzip -S指定壓縮文件后綴-mtime $KEEP_DAYS表示只看修改時間超過N天的文件。你拿到合集里的日志腳本時先確認它用的是-print0還是普通的-exec。如果是普通寫法且沒做過濾遇到帶空格的文件名大概率會翻車。3.3 數(shù)據(jù)庫備份類先看備份用的命令、壓縮方式、恢復腳本有沒有配齊數(shù)據(jù)庫備份腳本是風險最高的一類因為它的運行結果直接影響可用性。這類腳本我建議你只信“能恢復的備份”也就是備份完一定要有辦法驗證。選型時先看它用的是mysqldump、pg_dump還是文件系統(tǒng)快照方式再看有沒有配套的恢復腳本。# MySQL 備份腳本骨架按庫導出并壓縮 #!/usr/bin/env bash set -Eeuo pipefail DB_USER${DB_USER:-backup_user} DB_PASS${DB_PASS:-} DB_NAME${1:-} BACKUP_DIR${2:-/var/backups/mysql} if [ -z $DB_NAME ]; then echo 用法: $0 數(shù)據(jù)庫名 [備份目錄] 2 exit 2 fi STAMP$(date %Y%m%d_%H%M%S) mkdir -p $BACKUP_DIR mysqldump --single-transaction -u$DB_USER -p$DB_PASS $DB_NAME | gzip $BACKUP_DIR/${DB_NAME}_${STAMP}.sql.gz echo 備份完成: $BACKUP_DIR/${DB_NAME}_${STAMP}.sql.gz數(shù)據(jù)庫腳本最重要的參數(shù)是--single-transaction它保證備份期間不鎖表在線備份時尤其關鍵。用戶名和密碼通過環(huán)境變量傳入而不是寫死在腳本里這是接手任何備份腳本時最應該先改的地方。備份完成后我會額外跑一次gzip -t來驗證壓縮包完整性再決定要不要保留這個腳本作為日常任務。3.4 網(wǎng)絡與連通性檢查以退出碼和超時為準別只看輸出網(wǎng)絡類腳本和其他腳本最大的不同是它的執(zhí)行結果受到外部環(huán)境干擾丟包、超時、DNS解析失敗都可能讓輸出變得不可信。挑這類腳本時重點看有沒有設置合理超時以及是否以退出碼作為判斷依據(jù)。# 連通性檢查帶超時并輸出結構化結果 #!/usr/bin/env bash set -Eeuo pipefail TARGET${1:-8.8.8.8} COUNT${2:-3} TIMEOUT${3:-2} if ping -c $COUNT -W $TIMEOUT $TARGET /dev/null 21; then echo reachable exit 0 else echo unreachable exit 1 fi這段代碼把輸出和退出碼綁在一起正常時輸出reachable并返回0失敗時輸出unreachable并返回1。-W是超時秒數(shù)-c是發(fā)包數(shù)量。注意ping的參數(shù)在 Linux 和 macOS 上不一樣macOS 用的是-t你如果腳本庫里混用了這兩個參數(shù)到了另一臺機器上就會直接報錯。這類腳本還有一點要注意就是不要把 ICMP 連通性和服務可用性混為一談端口通不通是另一層問題。4. 挑三個腳本做生產(chǎn)級改造參數(shù)化、配置化、退出碼一個都不能少279個腳本里真正能“開箱即用”的估計只有一半多另外一半要么是示例、要么是某個特定環(huán)境的寫法。我的經(jīng)驗是與其把這279個都用一遍不如挑三個最常用的改造到能直接進生產(chǎn)。改造的目標很簡單參數(shù)能傳、配置能改、退出碼能信。4.1 日志切割腳本改造把路徑和保留天數(shù)抽成參數(shù)先改造日志切割腳本。原始腳本很可能把路徑寫死在文件里比如LOG_DIR/var/log/nginx。這種寫死的問題是你復制到新機器上就必須打開文件改很容易改錯。改造后應該支持兩個參數(shù)日志目錄和保留天數(shù)。#!/usr/bin/env bash # 按天切割日志保留 N 天 # 用法: log_rotate.sh 日志目錄 [保留天數(shù)] set -Eeuo pipefail LOG_DIR${1:?必須指定日志目錄} KEEP_DAYS${2:-7} if [ ! -d $LOG_DIR ]; then echo [ERROR] 目錄不存在: $LOG_DIR 2 exit 2 fi # 第一步壓縮現(xiàn)有 *.log find $LOG_DIR -maxdepth 1 -type f -name *.log -print0 | while IFS read -r -d f; do gzip -S .$(date %Y%m%d).gz $f done # 第二步清理超過保留天數(shù)的壓縮包 # 注意-mtime 的數(shù)值是“超過 N 天”保守起見可以加 1 find $LOG_DIR -maxdepth 1 -type f -name *.gz -mtime $((KEEP_DAYS1)) -delete echo [OK] $LOG_DIR 切割完成保留 $KEEP_DAYS 天這次改造有三個關鍵變化。第一個是${1:?必須指定日志目錄}這個寫法會在參數(shù)為空時報錯并退出避免后續(xù)所有命令拿空值去執(zhí)行。第二個是KEEP_DAYS的默認值7天調(diào)用者不傳也能跑。第三個是刪除條件用了$((KEEP_DAYS1))也就是保留N天多一點防止剛切割完的文件因為時間邊界被誤刪。實踐中最容易翻車的就是這個保留天數(shù)邊界建議按“多留一天”來改刪文件條件。4.2 磁盤告警腳本改造閾值參數(shù)化告警通道和檢測邏輯分離磁盤告警腳本是另一個高頻改造對象。最初的版本往往只負責“檢測加打印”能不能真正告警取決于你把它接到哪里。我習慣把告警動作單獨拆出去檢測腳本只負責判斷和輸出告警邏輯通過回調(diào)函數(shù)或環(huán)境變量來指定。#!/usr/bin/env bash # 磁盤使用率告警閾值作為參數(shù) # 用法: disk_alert.sh [閾值] [文件系統(tǒng)] set -Eeuo pipefail THRESHOLD${1:-80} FILESYSTEM${2:-/} USAGE$(df -h $FILESYSTEM | awk NR2 {gsub(%,,$5); print $5}) if [ $USAGE -ge $THRESHOLD ]; then echo [ALERT] $FILESYSTEM 使用率 ${USAGE}% 超過閾值 ${THRESHOLD}% # 告警通道由環(huán)境變量決定不在腳本里寫死 # 調(diào)用側示例: ALERT_CMDcurl -s -X POST http://alert-server/api if [ -n ${ALERT_CMD:-} ]; then $ALERT_CMD $FILESYSTEM $USAGE fi exit 1 fi echo [OK] $FILESYSTEM 使用率 ${USAGE}% exit 0改造的重點是把“告警方式”從腳本里摘出去。你在這臺機器上可能想發(fā)HTTP請求到告警平臺在另一臺機器上只想寫日志如果腳本寫死了告警方式就很難復用。用ALERT_CMD環(huán)境變量把告警命令交給調(diào)用者定義腳本本身只做檢測和判斷。這里沒有給$ALERT_CMD加引號是刻意讓 shell 按空格分詞把命令和參數(shù)拆開這種寫法對安全邊界有要求所以注釋里寫清楚了調(diào)用側負責定義可信命令。4.3 批量執(zhí)行器改造處理空行、注釋、引號防止命令被拆碎批量執(zhí)行器的作用是從一個主機列表文件里逐行讀服務器然后統(tǒng)一執(zhí)行命令。這種腳本看起來簡單但最容易出問題的是文件讀取邏輯。沒有經(jīng)驗的寫法是for i in $(cat list)一旦列表里有空格或空行處理邏輯就會崩。更穩(wěn)妥的是用while read配合IFS。#!/usr/bin/env bash # 批量執(zhí)行器從文件逐行讀取主機并執(zhí)行命令 # 用法: batch_exec.sh 主機列表.txt [命令] set -Eeuo pipefail HOSTS_FILE${1:?必須指定主機列表文件} CMD${2:-uptime} if [ ! -f $HOSTS_FILE ]; then echo [ERROR] 文件不存在: $HOSTS_FILE 2 exit 2 fi # 逐行讀取跳過空行與 # 開頭的注釋行 while IFS read -r host || [ -n $host ]; do case $host in |\#*) continue ;; esac echo $host ssh -o ConnectTimeout5 -o BatchModeyes $host $CMD done $HOSTS_FILE這段代碼里有三個關鍵點。第一IFS禁止行內(nèi)字段分割保證一行內(nèi)容完整進入host變量不會被空格切開。第二|| [ -n $host ]處理最后一行沒有換行符的情況避免最后一個主機被漏掉這是一個非常隱蔽的問題。第三用case匹配空行和#開頭的注釋行讓主機列表文件可以直接帶注釋方便維護。-o BatchModeyes讓 ssh 在無法交互時直接失敗而不是掛住配合ConnectTimeout5能避免批量執(zhí)行卡死。5. 生產(chǎn)環(huán)境跑這279個腳本5類避坑與排查記錄把腳本從“能跑”變成“敢在凌晨三點讓它自己跑”要過的坑比想象中多。下面這幾類是我在多個環(huán)境里反復踩過的按出現(xiàn)頻率從高到低排。5.1 現(xiàn)象腳本報“No such file or directory”但文件明明在這是 Windows 編輯腳本后最常見的翻車現(xiàn)場。你從 Windows 上傳到 Linux腳本第一行是#!/usr/bin/env bash執(zhí)行時卻報No such file or directory或者提示/usr/bin/env bash^M。原因很簡單文件是 CRLF 換行bash 解釋器把回車符當成了命令或路徑的一部分。解決方法是把所有腳本批量去掉\r# 批量把 CRLF 轉成 LF find . -name *.sh -exec sed -i s/\r$// {} \; # 驗證是否還有殘留回車 cat -A bin/disk_check.sh | grep -n \^M || echo 沒有殘留 ^M絕大多數(shù)腳本集合下載后是壓縮包不會強制轉行。如果你在 Windows 上用編輯器改過腳本改完一定記得轉回 LF。sed -i s/\r$//只去掉行尾回車不影響文件內(nèi)容里的其他字符。cat -A是驗證用的重要工具^M就是回車符的顯示形態(tài)。5.2 現(xiàn)象中文輸出亂碼腳本里寫的中文注釋全變成“錕斤拷”某些腳本里帶中文提示或日志說明運行環(huán)境語言環(huán)境不一樣就會出現(xiàn)亂碼。原因不是腳本本身壞了而是終端或機器的 locale 與腳本編碼不匹配。解決方向有兩個。一是統(tǒng)一把腳本編碼設成 UTF-8二是運行腳本前導出語言環(huán)境# 在 /etc/profile.d/ 或 ~/.bashrc 里固定語言環(huán)境 export LC_ALLC.UTF-8 export LANGC.UTF-8注意不要把LC_ALL隨便設成en_US.UTF-8因為服務器上不一定裝了對應的 locale 包硬設反而會在某些命令里報錯。C.UTF-8幾乎每個發(fā)行版都有。你接手腳本庫時可以先跑file 腳本名看編碼如果是ISO-8859或GBK再考慮要不要轉換。5.3 現(xiàn)象腳本依賴的命令本機沒有跑一半就退出279個腳本里會有不少依賴外部命令最典型的是mysql、jq、bc、getopt。內(nèi)網(wǎng)機器不一定允許隨便裝包。我見過有人在生產(chǎn)機器上因為沒有jq而臨時把 JSON 解析腳本改成grep sed這種做法短期可行但不好維護。更好的做法是先做依賴檢查和降級方案# 依賴命令缺失時的優(yōu)雅退出 if ! command -v jq /dev/null 21; then echo [WARN] jq 未安裝跳過 JSON 解析功能 2 exit 3 fi這類腳本最關鍵的是“提前退出”而不是“跑到一半崩掉”。退出碼用3這類業(yè)務碼而不是127的 command not found方便上層平臺區(qū)分原因。如果你確實要跑一個必須依賴某命令的腳本那就老老實實裝依賴不要用 sed 硬解析 JSON那會讓后續(xù)維護成本失控。5.4 現(xiàn)象腳本里有 rm 刪除不知道會刪到哪腳本合集里肯定有一批帶rm -rf或find ... -delete的清理腳本。這類腳本風險最高。不要以為作者寫對了就不會出事路徑拼錯一個字符就可能是災難。我的處理習慣是拿到腳本后先做一次刪除動作審計再決定要不要上生產(chǎn)。# 先列出腳本里所有刪除動作只讀審計 grep -nE rm(-rf)?\s|find\s.*-delete bin/*.sh這一步不執(zhí)行刪除只是把風險點列出來。看到rm -rf時先確認它的目標路徑是否由固定值或參數(shù)控制再看有沒有前置的目錄存在性判斷。比如rm -rf $LOG_DIR/*和rm -rf $LOG_DIR完全是兩碼事前者刪文件后者連目錄一起刪。腳本里如果出現(xiàn)絕對路徑寫死的刪除并且沒有參數(shù)保護我一般會改成相對路徑加變量甚至直接停用。5.5 現(xiàn)象定時任務里腳本不輸出退出碼為0但什么都沒干腳本手動跑正常放進 crontab 之后要么不執(zhí)行要么執(zhí)行了但日志找不到。最常見的兩個原因一個是 cron 環(huán)境里的 PATH 和你交互終端里的 PATH 不一樣腳本里用的命令找不到另一個是腳本輸出重定向到某個不存在的目錄cron 直接丟棄輸出。# 在腳本頂部固定 PATH 和關鍵變量 export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin export TZUTC把 PATH 寫死在腳本頂部而不是依賴用戶環(huán)境是讓腳本能在 cron 里穩(wěn)定運行的底線操作。除了 PATH還要檢查腳本里有沒有用相對路徑cron 的工作目錄默認是用戶家目錄相對路徑很容易失效。日志文件盡量用絕對路徑并確保腳本運行時日志目錄已經(jīng)存在。6. 把279個腳本變成自己的養(yǎng)成“注釋即文檔、模板即復用”的小習慣腳本庫跑通只是第一步真正讓這279個腳本產(chǎn)生長期價值的方式是把它拆成自己能復用的模板而不是讓一個龐大的合集一直占據(jù)磁盤。我現(xiàn)在的維護方式很簡單所有腳本只要經(jīng)過改造就把用法注釋寫成一兩行并保持統(tǒng)一的參數(shù)風格。6.1 給每個腳本加 usage 函數(shù)替代散落的 echo我習慣在每個腳本開頭加一個usage()函數(shù)把接受的參數(shù)列出來再在主邏輯里判斷$#是否足夠。這種做法的收益很直接三個月后你回來看腳本不用靠回憶別人接手時也不用打開正文讀一遍。#!/usr/bin/env bash set -Eeuo pipefail usage() { cat EOF 用法: $(basename $0) 日志目錄 [保留天數(shù)] 示例: $(basename $0) /var/log/nginx 14 EOF exit 2 } [ $# -lt 1 ] usage LOG_DIR$1 KEEP_DAYS${2:-7}6.2 從279個腳本里抽3個模板而不是背誦所有腳本把這個合集堅持用了三個月之后我最大的心得是不要試圖記住每個腳本而是總結出三個自己最常用的模板例如“參數(shù)校驗加退出碼加輸出規(guī)范”的巡檢類模板、“環(huán)境變量加默認值加日志切割”的清理類模板、“while read加跳過注釋加超時控制”的批量操作類模板。遇到新需求時先在模板上改而不是翻合集從頭找。6.3 驗證腳本回歸改一行之后跑一次它的反例每次改動腳本之后我習慣跑它最容易出錯的反例比如不傳參數(shù)、傳空目錄、把閾值設成0。驗證一遍不是為了說服自己它能跑而是確認失敗路徑是可預期的。這個習慣救過我一次日志切割腳本改完保留天數(shù)后當天晚上定時任務跑完沒誤刪就是因為提前測了“目錄不存在”和“文件為空”這兩種情況。一套腳本敢用多久不取決于它當時寫了多好而取決于你改它的時候有多穩(wěn)。希望幫到你。本文還有配套的精品資源點擊獲取