must函数只适用于初始化阶段等“失败即崩溃”的场景，如解析硬编码模板、加载内置配置；不可用于用户输入或io操作，因其掩盖错误类型且妨碍调试与可观测性。
“Must”函数不是语法糖，而是明确放弃错误恢复能力的信号——只该用在初始化阶段、配置加载、模板编译等“失败即崩溃”的场景。
什么时候该用template.Must这类函数？
它只适合那些本就不该失败、且失败后程序无法继续运行的操作。比如解析硬编码的模板字符串、加载内置 JSON 配置、初始化全局 logger 实例。
- ✅ 适用：启动时读取内嵌模板
template.Must(template.New("t").Parse(htmlStr)) - ❌ 不适用：处理用户上传的模板文件——此时应返回
error并由上层决定重试或提示 - ⚠️ 注意：
Must函数内部 panic 的堆栈会直接暴露调用点，不利于调试定位原始错误来源（比如 panic 是因为 Parse 失败，但真正原因是 htmlStr 为空）
Must函数为什么不能随便封装自己写的逻辑？
自定义 Must 容易掩盖真实错误语义，尤其当底层函数本就该返回可分类错误时。
- 比如封装
MustOpenFile：如果只是简单os.Open+panic，那所有失败原因（权限拒绝、路径不存在、设备忙）都变成同一个 panic，无法区分处理 - 标准库中
template.Must和regexp.MustCompile的共同点是：输入完全可控（字符串字面量）、失败意味着代码缺陷而非运行时异常 - 若真要封装，必须确保错误类型单一、上下文清晰，且调用方已承诺承担 panic 后果
用Must还是显式if err != nil？关键看控制流归属
判断依据不是“写起来简不简洁”，而是“谁该对失败负责”。
- 主流程外的初始化：交给
Must，让 panic 在main或init中快速暴露问题 - 业务逻辑中的 IO 或网络调用：必须显式检查
err，因为失败是常态，需要重试、降级或用户反馈 - 测试中慎用
Must：它会让测试因 panic 而中断，掩盖本应被断言捕获的错误行为
真正容易被忽略的是：Must 没有替代错误分类和可观测性设计的能力。哪怕你用了 template.Must，也得确保 panic 日志里能打出来原始错误信息——否则下次模板出错，你只能看到一行 panic: template: ...，而不知道到底是语法错还是变量名拼错了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
