PowerShell

600 个脚本，一种哲学：拆解 fleschutz/PowerShell 的“脚本即工具”路线

项目背景与痛点

跨平台运维有一个长期未被满足的空白：我需要一个“就干这一件事”的小工具，能同时在 Windows、Linux、macOS 上跑，不需要装运行时、不需要写三份代码、不需要记三套命令。

Bash 只在 Unix 侧成立；Python 要环境，还要处理依赖与版本；Go 编译出来的二进制虽好，但你得先会写 Go。PowerShell Core 跨平台之后，成了少数“三大 OS 原生可用、对象管道、无需额外运行时”的脚本层。可 PowerShell 生态的主流做法仍是模块化：把函数打包成 Module，上传 PSGallery，用户 Install-Module 后再拼装调用。对“我只想 ping 一下并格式化输出”的人来说，这套流程太重了。

fleschutz/PowerShell 走的是完全相反的路：不做模块，直接做应用。600+ 个独立 .ps1，一个文件对应一件事——查系统信息、扫磁盘、备份目录、切深色模式、转图片格式、诊断网络。它把 Unix “单职责小工具”的哲学，搬进了 PowerShell 的跨平台语境。

核心技术揭秘

这个项目没有复杂框架，它的技术含量恰恰在“没有框架”上。整体是三层：平铺脚本库 + 可发现性入口 + 平台适配分支。

几个值得说的设计决策：

1. 自包含脚本（Self-contained Script） 每个脚本都带完整的 comment-based help（.SYNOPSIS、.DESCRIPTION、.EXAMPLE）、自己的 param() 块、自己的输出逻辑。副作用是重复代码极多，收益是任何单个文件复制走都能独立运行。这是刻意的取舍：可移植性优先于 DRY。

2. 适配器式平台分支 脚本内部普遍用 $IsWindows / $IsLinux / $IsMacOS 分流到不同原生命令。这里的真实难点不在判断，而在输出解析：df -h 在 GNU 与 BSD 下字段对齐不同，lsblk 在 macOS 根本不存在，systemctl 与 launchctl 语义完全两套。项目采用的是“把非结构化文本解析成 PSObject，再统一 Format-Table / ConvertTo-Json”的胶水策略——本质上是把 Unix 的文本流重新接回 PowerShell 的对象管道。

3. 启动器即“应用商店” 600 个脚本最大的敌人不是写，是找不到。项目根目录的 run-script.ps1 类脚本承担了索引与模糊检索的职责，把“一个目录”变成“一个可浏览的工具集”。这是整个仓库的可用性关键：没有它，600 个文件名就是一片噪音。

4. 约定优于配置 命名统一走 动词-名词（check-ping、list-installed-software、switch-to-dark-mode），颜色输出、错误提示、退出码风格趋同。这种一致性让脚本之间可以互相“读懂”，也让用户可以盲猜命令名。

功能亮点与差异

对比同类方案，它的杀手锏有三个：

• 密度：600+ 的覆盖面，从系统盘点、网络诊断到图像转换、注册表调整，是“日常杂活”的合集，而不是某个垂直领域的深挖。
• 零依赖分发：git clone 后即可执行，不依赖 PSGallery、不依赖第三方模块。这在离线环境与被管控的企业终端上很实用。
• 源码即文档：每个脚本几十行，可读、可改、可抄。它同时是一个 PowerShell 跨平台写法的教学语料库——这一点常被低估。

与 PSGallery 模块相比，它是应用层而非库层；与各类 bash 脚本集相比，它跨平台；与 Ansible/Puppet 相比，它是单机即时操作，不做状态收敛。三者不在同一赛道，也正因此它补上了中间那块空白。

应用场景与落地建议

适合：个人与团队的工具箱、CI 中的临时诊断步骤、新人学习 PowerShell 跨平台写法的样本库、快速原型的起点。

生产环境需要注意：

1. 不要 iwr | iex 直接跑远程脚本。先 clone 到固定路径，审阅后再执行，这是唯一可靠的安全边界。
2. 质量参差。600 个脚本出自社区贡献，没有统一的 Pester 测试与 CI 门禁，部分脚本依赖特定外部程序或特定发行版。用到哪个，先读哪个。
3. 危险操作要隔离。涉及磁盘清理、分区、注册表、服务启停的脚本，先在容器或虚拟机里跑一遍。
4. 执行策略与提权。Windows 侧的 ExecutionPolicy、Unix 侧的 sudo 交互，都要在自动化流程里显式处理，否则会卡在交互提示上。
5. 固定版本。clone 后打 tag 或锁 commit，避免上游变动导致流水线漂移。真要用进核心流程，建议把选中的脚本重写进自己的模块，享受版本与测试保障。

综合评价

优点：密度罕见、可发现性设计到位、零依赖跨平台、源码短小可审计可改写。它解决的是“我知道要做什么，只差一条命令”这个高频且长期被忽视的场景。

缺点：重复代码严重、缺少模块化与共享抽象、几乎没有测试与质量门禁、安全模型完全依赖使用者的自觉。它更像一个高质量的工具集市，而不是一个工程化的产品。

一句话总结：它不是让你“依赖”的库，而是让你“拿走”的脚本。用得对，它是效率倍增器；用得莽，它是一堆没人替你兜底的 rm -rf。