“显式优于隐式”的设计哲学
“显式优于隐式”（Explicit is better than implicit）是编程界（尤其是 Python 社区）广为推崇的一条核心设计哲学，出自《The Zen of Python》（Python 之禅）。但它不仅适用于 Python，更是高质量软件设计的通用原则。
一、字面意思
- 显式（Explicit）：行为、逻辑、依赖、意图 清晰、直接、明确地写出来。
- 隐式（Implicit）：行为靠“猜测”“约定”“魔法”或“副作用”实现，不直接可见。
✅ 显式：我知道这行代码做了什么。
❌ 隐式：这行代码背后可能触发一连串我看不见的操作。
二、举个简单例子
❌ 隐式（不推荐）：
// 看似简单，但 "save()" 内部可能：
// - 自动验证数据
// - 自动发网络请求
// - 自动刷新 UI
// - 自动打日志
user.save();
→ 你不知道 save() 到底干了什么，除非去看源码。
✅ 显式（推荐）：
validate(user);
const response = await api.updateUser(user);
ui.refreshUserProfile(response);
logger.log('User saved', user.id);
→ 每一步都清晰可见，意图明确，易于调试、测试、修改。
三、回到你的 mapKeys 函数
你问到 skipNullish 有没有意义？
从“显式优于隐式”角度看：
隐式设计（不提供选项）：
“函数内部自动处理 null，你不用管。”
→ 用户不知道是否处理了 null，也无法控制行为。
显式设计（提供 skipNullish 选项）：
“是否跳过 null/undefined？你来决定。”
→ 行为可配置、意图明确、文档清晰，即使默认值是 false，也告诉用户：“这个边界情况我们考虑了，你可以控制它。”
✅ 这就是“显式优于隐式”：把控制权和透明度交给用户，而不是藏在黑盒里。
四、更多经典场景
| 场景 | 隐式（坏） | 显式（好） |
|------|----------|----------|
| 依赖注入 | 全局单例 DB.connect() | 构造函数传入 new Service(db) |
| 类型系统 | 动态语言靠注释说明类型 | TypeScript 明确写 name: string |
| 配置 | 魔法字符串 "prod" | 枚举 Env.PRODUCTION |
| 错误处理 | 静默失败 | 显式 throw 或返回 Result<Error, T> |
五、为什么“显式”更好？
- 可读性：代码即文档，新人也能快速理解。
- 可维护性：修改时知道影响范围。
- 可测试性：每个行为可独立验证。
- 可预测性：没有“惊喜”（surprises）。
- 减少魔法：避免“它居然能运行？！”的困惑。
六、但要注意：显式 ≠ 冗长
❌ 显式 ≠ 写 10 行代码做 1 件事
✅ 显式 = 在关键决策点暴露意图
比如：
- 提供 mode: 'replace' | 'copy' 是显式（让用户选择行为）。
- 但不必让用户手动写递归逻辑（那是重复造轮子）。
总结
“显式优于隐式” = 让代码的意图、行为、边界条件清晰可见，而不是靠猜测、约定或隐藏逻辑。
在你的 mapKeys 函数中：
- 提供 options 而不是硬编码行为 → ✅ 显式
- 用 ignoreKeys 明确保护关键字段 → ✅ 显式
- 文档说明 skipNullish 的作用 → ✅ 显式
这正是专业级工具库的体现 👏。
🐍 正如《Python 之禅》所说：
“Explicit is better than implicit.”
—— 让代码说出它的真实意图。