【免費下載鏈接】Dev-JanitorCross-platform desktop app for cleaning development artifacts, managing local developer tools, and checking common environment issues.項目地址https://gitcode.com/gh_mirrors/de/Dev-Janitor點擊查看免費下載Dev Janitor 是一款跨平臺桌面應用用于清理開發(fā)殘留、管理本地開發(fā)工具并檢查常見環(huán)境問題。它的文件清理引擎在設計上有個核心原則寧可漏刪不可誤刪。本文解析其模式匹配、目錄剪枝與防誤刪白名單策略幫你理解一個安全清理引擎的分層設計思路。為什么安全刪除是清理工具的第一問題開發(fā)環(huán)境里看起來像垃圾的文件和真正是垃圾的文件往往只差一層目錄。比如.copilot/目錄里既有可清理的會話緩存也有正在使用的配置文件。清理引擎一旦把兩者混為一談用戶丟失的可能不是緩存而是數(shù)周的工作配置。Dev Janitor 的清理引擎源碼集中在 ai_cleanup/mod.rs整體采用三層防線 刪除前終驗的架構模式匹配識別目標但刻意只打靶具體文件目錄剪枝命中即跳過整棵子樹避免重復報告白名單在掃描和刪除兩個階段都兜底保護關鍵資產刪除前終驗刪除動作單獨再做一次完整校驗。第一層模式匹配——只認垃圾特征不認目錄名引擎定義了三類特征庫全部是垃圾特征而非工具特征AI 工具殘留模式AI_TOOL_PATTERNS在 ai_cleanup/mod.rs 中模式表精確指向各 AI 編程工具確定可再生的產物例如.aider.chat.history.md、.aider.tags.cacheAider 歷史與緩存.copilot/session-state、.copilot/session-store.dbCopilot CLI 會話數(shù)據(jù).qwen/.cache、.cline/cache、.windsurf等緩存目錄一個關鍵細節(jié)check_ai_tool_patternai_cleanup/mod.rs對不帶路徑分隔符的模式只做文件名相等或以其開頭匹配對帶路徑的模式才做后綴/包含匹配。這意味著它不會把整個.copilot配置目錄當成垃圾——只有session-state、session-store.db這兩個會話目標會被命中。項目里的測試用例如 detects_copilot_cli_session_targets_without_config_noise專門驗證了這一點配置目錄保留會話緩存命中。臨時文件模式TEMP_FILE_PATTERNS覆蓋編輯器與系統(tǒng)的常見臨時產物ai_cleanup/mod.rs.swp、.bak、.DS_Store、Thumbs.db等用文件名等于或以模式結尾的方式匹配。異常文件啟發(fā)式check_anomalousai_cleanup/mod.rs 還有一組啟發(fā)式規(guī)則零字節(jié)文件、可疑的單字符文件名、純特殊字符命名。注意它給.gitkeep這類已知合法的空文件開了豁免——啟發(fā)式規(guī)則同樣要留白名單。第二層目錄剪枝——命中即整棵跳過掃描主循環(huán)scan_targetai_cleanup/mod.rs在遍歷目錄時一旦命中白名單目錄或垃圾目錄就調用entries.skip_current_dir()直接剪掉整棵子樹。這帶來兩個好處性能不再遍歷已知無意義的深層內容去重一個垃圾目錄只報告一次不會出現(xiàn)目錄 目錄里 10 個文件共 11 條重復結果。測試 reports_matching_directory_once_without_descendant_duplicates 專門鎖定了這個行為。此外scan_ai_junkai_cleanup/mod.rs最后還按完整路徑去重并用 rayon 并行掃描多個目標目錄結果按大小降序排列——用戶先看到的永遠是最值得清理的大塊頭。第三層防誤刪白名單——關鍵資產永不進入視野白名單是掃描階段的硬邊界由is_whitelistedai_cleanup/mod.rs實現(xiàn)分兩類白名單內容保護對象WHITELIST_DIRECTORIES.git、node_modules、target、venv等L110-L121版本庫、依賴與構建產物WHITELIST_EXTENSIONSpdf、docx、psd、raw、zip等L100-L108文檔、音視頻、設計源文件、壓縮包設計上有兩層考量版本庫和數(shù)據(jù)文件絕不被當垃圾.git被剪枝意味著清理引擎看不見倉庫歷史非代碼資產優(yōu)先保護psd、raw、cr2這類源文件一旦誤刪無法恢復白名單按擴展名一票否決。配合根目錄掃描的深度鉗制ROOT_SCAN_MAX_DEPTH 8ai_cleanup/mod.rs即使用戶誤選掃描盤符根目錄引擎也會把目標收斂到用戶主目錄并限制遞歸深度把爆炸半徑控制在最小。刪除前終驗validate_ai_junk_delete_target 的五道門掃描階段說這可能是垃圾刪除階段則獨立再驗一遍。delete_ai_junkai_cleanup/mod.rs在執(zhí)行刪除前先調用validate_ai_junk_delete_targetai_cleanup/mod.rs過五道門符號鏈接拒絕canonicalize_existing_pathL298-L310檢測到目標是符號鏈接時直接拒絕——防止指向別處的快捷方式繞過校驗把鏈接目標刪掉根目錄與主目錄拒絕is_root_or_home_pathL312-L321攔截對/和~的刪除請求白名單復查刪除路徑再過一次is_whitelisted即使掃描結果被截斷或緩存過期也有兜底二次特征匹配路徑必須仍能命中 AI 殘留、臨時文件或異常規(guī)則之一否則報Path is not a recognized AI junk target拒絕執(zhí)行平臺級保留名攔截Windows 下額外攔截con、nul等保留名L502-L517。刪除失敗時還有分級重試Windows 下去只讀屬性后重試fix_permissions_and_deleteL566-L593Unix 下chmod補寫權限后重試L596-L611。前后端如何協(xié)作命令通道與確認彈窗Rust 核心能力通過 Tauri 命令暴露給前端入口在 commands/ai_cleanup.rsscan_ai_junk_cmd接收路徑與maxDepth并做了maxDepth.min(20)的硬上限鉗制防止 UI 傳入異常深度delete_ai_junk_cmd/delete_multiple_ai_junk批量刪除每個路徑獨立返回結果單條失敗不影響其余。前端封裝在 ipc/commands.ts實際實現(xiàn)見 ipc/commands.ts 的safeInvoke調用。界面?zhèn)華iCleanupView.tsx在刪除前彈出ConfirmDialogL421把最終決定權交還給用戶——引擎負責收斂候選集人負責最后確認。小結可復用的安全清理引擎清單如果你也想給工具加一個清理功能Dev Janitor 的做法可以濃縮成一張清單? 垃圾特征指向可再生產物緩存、歷史、會話不指向配置與項目資產? 白名單在掃描、刪除兩個階段各執(zhí)行一次? 命中即剪枝保證結果去重且性能可控? 刪除前獨立終驗符號鏈接、根/主目錄、白名單、特征二次匹配? 深度上限鉗制根目錄 8 層、命令層 20 層控制爆炸半徑;? 平臺差異保留名、權限單獨處理失敗可分級重試? 用戶確認彈窗作為最后一道閘。清理類功能的可靠性不來自識別得多準而來自每一層都可能出錯時下一層還能攔住。這就是 Dev Janitor 清理引擎最值得借鑒的設計哲學。output文章 /output文章Wait, I made a typo above. Let me redo the final answer properly. 輸出文章如何設計安全的文件清理引擎解析 Dev Janitor 的模式匹配、目錄剪枝與防誤刪白名單策略Dev Janitor 是一款跨平臺桌面應用用于清理開發(fā)殘留、管理本地開發(fā)工具并檢查常見環(huán)境問題。它的文件清理引擎在設計上有個核心原則寧可漏刪不可誤刪。本文解析其模式匹配、目錄剪枝與防誤刪白名單策略幫你理解一個安全清理引擎的分層設計思路。為什么安全刪除是清理工具的第一問題開發(fā)環(huán)境里看起來像垃圾的文件和真正是垃圾的文件往往只差一層目錄。比如.copilot/目錄里既有可清理的會話緩存也有正在使用的配置文件。清理引擎一旦把兩者混為一談用戶丟失的可能不是緩存而是數(shù)周的工作配置。Dev Janitor 的清理引擎源碼集中在 ai_cleanup/mod.rs整體采用三層防線 刪除前終驗的架構模式匹配識別目標但刻意只打靶具體文件目錄剪枝命中即跳過整棵子樹避免重復報告白名單在掃描和刪除兩個階段都兜底保護關鍵資產刪除前終驗刪除動作單獨再做一次完整校驗。第一層模式匹配——只認垃圾特征不認目錄名引擎定義了三類特征庫全部是垃圾特征而非工具特征AI 工具殘留模式AI_TOOL_PATTERNS在 ai_cleanup/mod.rs 中模式表精確指向各 AI 編程工具確定可再生的產物例如.aider.chat.history.md、.aider.tags.cacheAider 歷史與緩存.copilot/session-state、.copilot/session-store.dbCopilot CLI 會話數(shù)據(jù).qwen/.cache、.cline/cache、.windsurf等緩存目錄一個關鍵細節(jié)check_ai_tool_patternai_cleanup/mod.rs對不帶路徑分隔符的模式只做文件名相等或以其開頭匹配對帶路徑的模式才做后綴/包含匹配。這意味著它不會把整個.copilot配置目錄當成垃圾——只有session-state、session-store.db這類會話目標會被命中。項目測試用例如 detects_copilot_cli_session_targets_without_config_noise專門驗證了這一點配置目錄保留會話緩存命中。臨時文件模式TEMP_FILE_PATTERNS覆蓋編輯器與系統(tǒng)的常見臨時產物ai_cleanup/mod.rs.swp、.bak、.DS_Store、Thumbs.db等用文件名等于或以模式結尾的方式匹配。異常文件啟發(fā)式check_anomalousai_cleanup/mod.rs 還有一組啟發(fā)式規(guī)則零字節(jié)文件、可疑的單字符文件名、純特殊字符命名。注意它給.gitkeep這類已知合法的空文件開了豁免——啟發(fā)式規(guī)則同樣要留白名單。第二層目錄剪枝——命中即整棵跳過掃描主循環(huán)scan_targetai_cleanup/mod.rs在遍歷目錄時一旦命中白名單目錄或垃圾目錄就調用entries.skip_current_dir()直接剪掉整棵子樹。這帶來兩個好處性能不再遍歷已知無意義的深層內容去重一個垃圾目錄只報告一次不會出現(xiàn)目錄 目錄里 10 個文件共 11 條重復結果。測試 reports_matching_directory_once_without_descendant_duplicates 專門鎖定了這個行為。此外scan_ai_junkai_cleanup/mod.rs最后還按完整路徑去重并用 rayon 并行掃描多個目標目錄結果按大小降序排列——用戶先看到的永遠是最值得清理的大塊頭。第三層防誤刪白名單——關鍵資產永不進入視野白名單是掃描階段的硬邊界由is_whitelistedai_cleanup/mod.rs實現(xiàn)分兩類白名單內容保護對象WHITELIST_DIRECTORIES.git、node_modules、target、venv等L110-L121版本庫、依賴與構建產物WHITELIST_EXTENSIONSpdf、docx、psd、raw、zip等L100-L108文檔、音視頻、設計源文件、壓縮包設計上有兩層考量版本庫和數(shù)據(jù)文件絕不被當垃圾.git被剪枝意味著清理引擎看不見倉庫歷史非代碼資產優(yōu)先保護psd、raw、cr2這類源文件一旦誤刪無法恢復白名單按擴展名一票否決。配合根目錄掃描的深度鉗制ROOT_SCAN_MAX_DEPTH 8ai_cleanup/mod.rs即使用戶誤選掃描盤符根目錄引擎也會把目標收斂到用戶主目錄并限制遞歸深度把爆炸半徑控制在最小。刪除前終驗validate_ai_junk_delete_target 的五道門掃描階段說這可能是垃圾刪除階段則獨立再驗一遍。delete_ai_junkai_cleanup/mod.rs在執(zhí)行刪除前先調用validate_ai_junk_delete_targetai_cleanup/mod.rs過五道門符號鏈接拒絕canonicalize_existing_pathL298-L310檢測到目標是符號鏈接時直接拒絕——防止指向別處的快捷方式繞過校驗把鏈接目標刪掉根目錄與主目錄拒絕is_root_or_home_pathL312-L321攔截對/和~的刪除請求白名單復查刪除路徑再過一次is_whitelisted即使掃描結果被截斷或緩存過期也有兜底二次特征匹配路徑必須仍能命中 AI 殘留、臨時文件或異常規(guī)則之一否則報Path is not a recognized AI junk target拒絕執(zhí)行平臺級保留名攔截Windows 下額外攔截con、nul等保留名L502-L517。刪除失敗時還有分級重試Windows 下去只讀屬性后重試fix_permissions_and_deleteL566-L593Unix 下chmod補寫權限后重試L596-L611。前后端如何協(xié)作命令通道與確認彈窗Rust 核心能力通過 Tauri 命令暴露給前端入口在 commands/ai_cleanup.rsscan_ai_junk_cmd接收路徑與maxDepth并做了maxDepth.min(20)的硬上限鉗制L12防止 UI 傳入異常深度delete_ai_junk_cmd/delete_multiple_ai_junk批量刪除每個路徑獨立返回結果單條失敗不影響其余。前端封裝在 ipc/commands.ts通過safeInvoke調用上述命令。界面?zhèn)華iCleanupView.tsx在刪除前彈出ConfirmDialogL421把最終決定權交還給用戶——引擎負責收斂候選集人負責最后確認。小結可復用的安全清理引擎清單如果你也想給工具加一個清理功能Dev Janitor 的做法可以濃縮成一張清單? 垃圾特征指向可再生產物緩存、歷史、會話不指向配置與項目資產? 白名單在掃描、刪除兩個階段各執(zhí)行一次? 命中即剪枝保證結果去重且性能可控? 刪除前獨立終驗符號鏈接、根/主目錄、白名單、特征二次匹配? 深度上限鉗制根目錄 8 層、命令層 20 層控制爆炸半徑? 平臺差異保留名、權限單獨處理失敗可分級重試? 用戶確認彈窗作為最后一道閘。清理類功能的可靠性不來自識別得多準而來自每一層都可能出錯時下一層還能攔住。這就是 Dev Janitor 清理引擎最值得借鑒的設計哲學。贊分享【免費下載鏈接】Dev-JanitorCross-platform desktop app for cleaning development artifacts, managing local developer tools, and checking common environment issues.項目地址https://gitcode.com/gh_mirrors/de/Dev-Janitor點擊查看免費下載相關推薦openGym 完全新手指南自托管健身追蹤器的 3 種運行方式從瀏覽器試用到部署自己的服務器openGym 完全新手指南自托管健身追蹤器的 3 種運行方式從瀏覽器試用到部署自己的服務器 openGym 是一款開源的自托管健身房與體重追蹤器self后端前端移動開發(fā)MCP 服務Nginx UI Auth 配置指南IP 白名單、可信代理與登錄安全策略Nginx UI Auth 配置指南IP 白名單、可信代理與登錄安全策略 本指南系統(tǒng)講解 Nginx UI 從 v2.0.0 beta.26 起引入的 aut后端前端運維認證鑒權從形狀正則到顯式白名單get-shit-done 安裝器 3628 修復如何防止 Hook 誤刪從形狀正則到顯式白名單get shit done 安裝器 3628 修復如何防止 Hook 誤刪 本文基于倉庫變更集文檔 3628 bundled hook人工智能AI 應用提示工程開發(fā)工具工作流自動化AI Agent創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 如何設計安全的文件清理引擎？解析 Dev Janitor 的模式匹配、目錄剪枝與防誤刪白名單策略
【免費下載鏈接】Dev-JanitorCross-platform desktop app for cleaning development artifacts, managing local developer tools, and checking common environment issues.項目地址https://gitcode.com/gh_mirrors/de/Dev-Janitor點擊查看免費下載Dev Janitor 是一款跨平臺桌面應用用于清理開發(fā)殘留、管理本地開發(fā)工具并檢查常見環(huán)境問題。它的文件清理引擎在設計上有個核心原則寧可漏刪不可誤刪。本文解析其模式匹配、目錄剪枝與防誤刪白名單策略幫你理解一個安全清理引擎的分層設計思路。為什么安全刪除是清理工具的第一問題開發(fā)環(huán)境里看起來像垃圾的文件和真正是垃圾的文件往往只差一層目錄。比如.copilot/目錄里既有可清理的會話緩存也有正在使用的配置文件。清理引擎一旦把兩者混為一談用戶丟失的可能不是緩存而是數(shù)周的工作配置。Dev Janitor 的清理引擎源碼集中在 ai_cleanup/mod.rs整體采用三層防線 刪除前終驗的架構模式匹配識別目標但刻意只打靶具體文件目錄剪枝命中即跳過整棵子樹避免重復報告白名單在掃描和刪除兩個階段都兜底保護關鍵資產刪除前終驗刪除動作單獨再做一次完整校驗。第一層模式匹配——只認垃圾特征不認目錄名引擎定義了三類特征庫全部是垃圾特征而非工具特征AI 工具殘留模式AI_TOOL_PATTERNS在 ai_cleanup/mod.rs 中模式表精確指向各 AI 編程工具確定可再生的產物例如.aider.chat.history.md、.aider.tags.cacheAider 歷史與緩存.copilot/session-state、.copilot/session-store.dbCopilot CLI 會話數(shù)據(jù).qwen/.cache、.cline/cache、.windsurf等緩存目錄一個關鍵細節(jié)check_ai_tool_patternai_cleanup/mod.rs對不帶路徑分隔符的模式只做文件名相等或以其開頭匹配對帶路徑的模式才做后綴/包含匹配。這意味著它不會把整個.copilot配置目錄當成垃圾——只有session-state、session-store.db這兩個會話目標會被命中。項目里的測試用例如 detects_copilot_cli_session_targets_without_config_noise專門驗證了這一點配置目錄保留會話緩存命中。臨時文件模式TEMP_FILE_PATTERNS覆蓋編輯器與系統(tǒng)的常見臨時產物ai_cleanup/mod.rs.swp、.bak、.DS_Store、Thumbs.db等用文件名等于或以模式結尾的方式匹配。異常文件啟發(fā)式check_anomalousai_cleanup/mod.rs 還有一組啟發(fā)式規(guī)則零字節(jié)文件、可疑的單字符文件名、純特殊字符命名。注意它給.gitkeep這類已知合法的空文件開了豁免——啟發(fā)式規(guī)則同樣要留白名單。第二層目錄剪枝——命中即整棵跳過掃描主循環(huán)scan_targetai_cleanup/mod.rs在遍歷目錄時一旦命中白名單目錄或垃圾目錄就調用entries.skip_current_dir()直接剪掉整棵子樹。這帶來兩個好處性能不再遍歷已知無意義的深層內容去重一個垃圾目錄只報告一次不會出現(xiàn)目錄 目錄里 10 個文件共 11 條重復結果。測試 reports_matching_directory_once_without_descendant_duplicates 專門鎖定了這個行為。此外scan_ai_junkai_cleanup/mod.rs最后還按完整路徑去重并用 rayon 并行掃描多個目標目錄結果按大小降序排列——用戶先看到的永遠是最值得清理的大塊頭。第三層防誤刪白名單——關鍵資產永不進入視野白名單是掃描階段的硬邊界由is_whitelistedai_cleanup/mod.rs實現(xiàn)分兩類白名單內容保護對象WHITELIST_DIRECTORIES.git、node_modules、target、venv等L110-L121版本庫、依賴與構建產物WHITELIST_EXTENSIONSpdf、docx、psd、raw、zip等L100-L108文檔、音視頻、設計源文件、壓縮包設計上有兩層考量版本庫和數(shù)據(jù)文件絕不被當垃圾.git被剪枝意味著清理引擎看不見倉庫歷史非代碼資產優(yōu)先保護psd、raw、cr2這類源文件一旦誤刪無法恢復白名單按擴展名一票否決。配合根目錄掃描的深度鉗制ROOT_SCAN_MAX_DEPTH 8ai_cleanup/mod.rs即使用戶誤選掃描盤符根目錄引擎也會把目標收斂到用戶主目錄并限制遞歸深度把爆炸半徑控制在最小。刪除前終驗validate_ai_junk_delete_target 的五道門掃描階段說這可能是垃圾刪除階段則獨立再驗一遍。delete_ai_junkai_cleanup/mod.rs在執(zhí)行刪除前先調用validate_ai_junk_delete_targetai_cleanup/mod.rs過五道門符號鏈接拒絕canonicalize_existing_pathL298-L310檢測到目標是符號鏈接時直接拒絕——防止指向別處的快捷方式繞過校驗把鏈接目標刪掉根目錄與主目錄拒絕is_root_or_home_pathL312-L321攔截對/和~的刪除請求白名單復查刪除路徑再過一次is_whitelisted即使掃描結果被截斷或緩存過期也有兜底二次特征匹配路徑必須仍能命中 AI 殘留、臨時文件或異常規(guī)則之一否則報Path is not a recognized AI junk target拒絕執(zhí)行平臺級保留名攔截Windows 下額外攔截con、nul等保留名L502-L517。刪除失敗時還有分級重試Windows 下去只讀屬性后重試fix_permissions_and_deleteL566-L593Unix 下chmod補寫權限后重試L596-L611。前后端如何協(xié)作命令通道與確認彈窗Rust 核心能力通過 Tauri 命令暴露給前端入口在 commands/ai_cleanup.rsscan_ai_junk_cmd接收路徑與maxDepth并做了maxDepth.min(20)的硬上限鉗制防止 UI 傳入異常深度delete_ai_junk_cmd/delete_multiple_ai_junk批量刪除每個路徑獨立返回結果單條失敗不影響其余。前端封裝在 ipc/commands.ts實際實現(xiàn)見 ipc/commands.ts 的safeInvoke調用。界面?zhèn)華iCleanupView.tsx在刪除前彈出ConfirmDialogL421把最終決定權交還給用戶——引擎負責收斂候選集人負責最后確認。小結可復用的安全清理引擎清單如果你也想給工具加一個清理功能Dev Janitor 的做法可以濃縮成一張清單? 垃圾特征指向可再生產物緩存、歷史、會話不指向配置與項目資產? 白名單在掃描、刪除兩個階段各執(zhí)行一次? 命中即剪枝保證結果去重且性能可控? 刪除前獨立終驗符號鏈接、根/主目錄、白名單、特征二次匹配? 深度上限鉗制根目錄 8 層、命令層 20 層控制爆炸半徑;? 平臺差異保留名、權限單獨處理失敗可分級重試? 用戶確認彈窗作為最后一道閘。清理類功能的可靠性不來自識別得多準而來自每一層都可能出錯時下一層還能攔住。這就是 Dev Janitor 清理引擎最值得借鑒的設計哲學。output文章 /output文章Wait, I made a typo above. Let me redo the final answer properly. 輸出文章如何設計安全的文件清理引擎解析 Dev Janitor 的模式匹配、目錄剪枝與防誤刪白名單策略Dev Janitor 是一款跨平臺桌面應用用于清理開發(fā)殘留、管理本地開發(fā)工具并檢查常見環(huán)境問題。它的文件清理引擎在設計上有個核心原則寧可漏刪不可誤刪。本文解析其模式匹配、目錄剪枝與防誤刪白名單策略幫你理解一個安全清理引擎的分層設計思路。為什么安全刪除是清理工具的第一問題開發(fā)環(huán)境里看起來像垃圾的文件和真正是垃圾的文件往往只差一層目錄。比如.copilot/目錄里既有可清理的會話緩存也有正在使用的配置文件。清理引擎一旦把兩者混為一談用戶丟失的可能不是緩存而是數(shù)周的工作配置。Dev Janitor 的清理引擎源碼集中在 ai_cleanup/mod.rs整體采用三層防線 刪除前終驗的架構模式匹配識別目標但刻意只打靶具體文件目錄剪枝命中即跳過整棵子樹避免重復報告白名單在掃描和刪除兩個階段都兜底保護關鍵資產刪除前終驗刪除動作單獨再做一次完整校驗。第一層模式匹配——只認垃圾特征不認目錄名引擎定義了三類特征庫全部是垃圾特征而非工具特征AI 工具殘留模式AI_TOOL_PATTERNS在 ai_cleanup/mod.rs 中模式表精確指向各 AI 編程工具確定可再生的產物例如.aider.chat.history.md、.aider.tags.cacheAider 歷史與緩存.copilot/session-state、.copilot/session-store.dbCopilot CLI 會話數(shù)據(jù).qwen/.cache、.cline/cache、.windsurf等緩存目錄一個關鍵細節(jié)check_ai_tool_patternai_cleanup/mod.rs對不帶路徑分隔符的模式只做文件名相等或以其開頭匹配對帶路徑的模式才做后綴/包含匹配。這意味著它不會把整個.copilot配置目錄當成垃圾——只有session-state、session-store.db這類會話目標會被命中。項目測試用例如 detects_copilot_cli_session_targets_without_config_noise專門驗證了這一點配置目錄保留會話緩存命中。臨時文件模式TEMP_FILE_PATTERNS覆蓋編輯器與系統(tǒng)的常見臨時產物ai_cleanup/mod.rs.swp、.bak、.DS_Store、Thumbs.db等用文件名等于或以模式結尾的方式匹配。異常文件啟發(fā)式check_anomalousai_cleanup/mod.rs 還有一組啟發(fā)式規(guī)則零字節(jié)文件、可疑的單字符文件名、純特殊字符命名。注意它給.gitkeep這類已知合法的空文件開了豁免——啟發(fā)式規(guī)則同樣要留白名單。第二層目錄剪枝——命中即整棵跳過掃描主循環(huán)scan_targetai_cleanup/mod.rs在遍歷目錄時一旦命中白名單目錄或垃圾目錄就調用entries.skip_current_dir()直接剪掉整棵子樹。這帶來兩個好處性能不再遍歷已知無意義的深層內容去重一個垃圾目錄只報告一次不會出現(xiàn)目錄 目錄里 10 個文件共 11 條重復結果。測試 reports_matching_directory_once_without_descendant_duplicates 專門鎖定了這個行為。此外scan_ai_junkai_cleanup/mod.rs最后還按完整路徑去重并用 rayon 并行掃描多個目標目錄結果按大小降序排列——用戶先看到的永遠是最值得清理的大塊頭。第三層防誤刪白名單——關鍵資產永不進入視野白名單是掃描階段的硬邊界由is_whitelistedai_cleanup/mod.rs實現(xiàn)分兩類白名單內容保護對象WHITELIST_DIRECTORIES.git、node_modules、target、venv等L110-L121版本庫、依賴與構建產物WHITELIST_EXTENSIONSpdf、docx、psd、raw、zip等L100-L108文檔、音視頻、設計源文件、壓縮包設計上有兩層考量版本庫和數(shù)據(jù)文件絕不被當垃圾.git被剪枝意味著清理引擎看不見倉庫歷史非代碼資產優(yōu)先保護psd、raw、cr2這類源文件一旦誤刪無法恢復白名單按擴展名一票否決。配合根目錄掃描的深度鉗制ROOT_SCAN_MAX_DEPTH 8ai_cleanup/mod.rs即使用戶誤選掃描盤符根目錄引擎也會把目標收斂到用戶主目錄并限制遞歸深度把爆炸半徑控制在最小。刪除前終驗validate_ai_junk_delete_target 的五道門掃描階段說這可能是垃圾刪除階段則獨立再驗一遍。delete_ai_junkai_cleanup/mod.rs在執(zhí)行刪除前先調用validate_ai_junk_delete_targetai_cleanup/mod.rs過五道門符號鏈接拒絕canonicalize_existing_pathL298-L310檢測到目標是符號鏈接時直接拒絕——防止指向別處的快捷方式繞過校驗把鏈接目標刪掉根目錄與主目錄拒絕is_root_or_home_pathL312-L321攔截對/和~的刪除請求白名單復查刪除路徑再過一次is_whitelisted即使掃描結果被截斷或緩存過期也有兜底二次特征匹配路徑必須仍能命中 AI 殘留、臨時文件或異常規(guī)則之一否則報Path is not a recognized AI junk target拒絕執(zhí)行平臺級保留名攔截Windows 下額外攔截con、nul等保留名L502-L517。刪除失敗時還有分級重試Windows 下去只讀屬性后重試fix_permissions_and_deleteL566-L593Unix 下chmod補寫權限后重試L596-L611。前后端如何協(xié)作命令通道與確認彈窗Rust 核心能力通過 Tauri 命令暴露給前端入口在 commands/ai_cleanup.rsscan_ai_junk_cmd接收路徑與maxDepth并做了maxDepth.min(20)的硬上限鉗制L12防止 UI 傳入異常深度delete_ai_junk_cmd/delete_multiple_ai_junk批量刪除每個路徑獨立返回結果單條失敗不影響其余。前端封裝在 ipc/commands.ts通過safeInvoke調用上述命令。界面?zhèn)華iCleanupView.tsx在刪除前彈出ConfirmDialogL421把最終決定權交還給用戶——引擎負責收斂候選集人負責最后確認。小結可復用的安全清理引擎清單如果你也想給工具加一個清理功能Dev Janitor 的做法可以濃縮成一張清單? 垃圾特征指向可再生產物緩存、歷史、會話不指向配置與項目資產? 白名單在掃描、刪除兩個階段各執(zhí)行一次? 命中即剪枝保證結果去重且性能可控? 刪除前獨立終驗符號鏈接、根/主目錄、白名單、特征二次匹配? 深度上限鉗制根目錄 8 層、命令層 20 層控制爆炸半徑? 平臺差異保留名、權限單獨處理失敗可分級重試? 用戶確認彈窗作為最后一道閘。清理類功能的可靠性不來自識別得多準而來自每一層都可能出錯時下一層還能攔住。這就是 Dev Janitor 清理引擎最值得借鑒的設計哲學。贊分享【免費下載鏈接】Dev-JanitorCross-platform desktop app for cleaning development artifacts, managing local developer tools, and checking common environment issues.項目地址https://gitcode.com/gh_mirrors/de/Dev-Janitor點擊查看免費下載相關推薦openGym 完全新手指南自托管健身追蹤器的 3 種運行方式從瀏覽器試用到部署自己的服務器openGym 完全新手指南自托管健身追蹤器的 3 種運行方式從瀏覽器試用到部署自己的服務器 openGym 是一款開源的自托管健身房與體重追蹤器self后端前端移動開發(fā)MCP 服務Nginx UI Auth 配置指南IP 白名單、可信代理與登錄安全策略Nginx UI Auth 配置指南IP 白名單、可信代理與登錄安全策略 本指南系統(tǒng)講解 Nginx UI 從 v2.0.0 beta.26 起引入的 aut后端前端運維認證鑒權從形狀正則到顯式白名單get-shit-done 安裝器 3628 修復如何防止 Hook 誤刪從形狀正則到顯式白名單get shit done 安裝器 3628 修復如何防止 Hook 誤刪 本文基于倉庫變更集文檔 3628 bundled hook人工智能AI 應用提示工程開發(fā)工具工作流自動化AI Agent創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考