真正好用的运维工具集需模块化设计、统一入口、配置分离与健壮性保障：按能力域切分模块并统一命名，通过toolmate路由子命令，支持多环境配置，且默认启用set -euo pipefail及输入校验。
想用Shell脚本搭一套真正好用、能长期维护的运维工具集，关键不在写多少行代码，而在结构是否清晰、职责是否分明、扩展是否自然。它不该是一堆零散脚本的堆砌，而应是一个有骨架、有接口、有呼吸感的系统。
模块化是起点，不是装饰
把所有功能塞进一个tools.sh里，初期看着省事，三个月后连自己都怕改。真正的模块化，是按“能力域”切分：比如navigation/专管目录跳转，git/封装常用操作，monitoring/只做指标采集和告警判断。每个模块对外暴露统一入口（如git.status、nav.to_logs），内部实现可替换，不影响调用方。
- 模块文件名带前缀，例如mod_git_status.sh、mod_sys_load.sh，便于排序与识别
- 模块内不直接执行逻辑，只定义函数；加载时由主调度器统一注册
- 模块间禁止硬依赖，需跨模块调用时，通过主调度器中转或共享基础函数库
统一入口 + 命令路由机制
用户不该记住一堆文件路径或source命令。设计一个轻量级入口脚本（比如叫toolmate），它本身不干活，只做三件事：加载核心、解析子命令、路由到对应模块。
- 支持toolmate git status、toolmate sys top这类两级命令，语义清晰
- 子命令解析用case配合位置参数，避免引入复杂框架
- 未识别命令自动提示可用列表，并标注模块来源，降低学习成本
配置与环境分离，支持多场景切换
开发机、测试服务器、生产集群，所需工具行为往往不同。硬编码配置会让脚本失去生命力。应在架构层面预留配置层：
- 主配置文件config.local.sh放在用户家目录，优先级最高，用于覆盖默认项
- 模块可声明自己的默认配置变量（如GIT_AUTO_PULL=true），但不强制生效
- 支持运行时指定环境：toolmate --env=prod sys check，触发不同告警阈值或日志路径
健壮性不是锦上添花，而是启动条件
运维脚本一旦出错，影响的是服务稳定性。从第一行就该建立防线：
- 所有模块脚本顶部强制包含set -euo pipefail，杜绝静默失败
- 关键路径（如日志目录、配置文件）在函数执行前校验存在性，不存在则友好退出并提示修复方式
- 对用户输入做最小化信任：参数含空格？路径含特殊字符？用双引号包裹变量、用printf %q转义再拼接命令
