go语言不推荐try/catch，主张用显式Error值处理可预见错误；panic仅用于不可恢复的严重异常，recover限于defer中捕获；设计哲学强调简洁、明确与可控。
Go语言不推荐使用类似try/catch的异常机制，其核心在于“错误是程序正常流程的一部分”这一设计理念。它主张通过返回error值来处理问题，而非抛出中断执行流的异常。这种方式让错误处理变得显式、直接且易于追踪。
错误即值：显式处理代替控制流跳转
Go认为大多数错误是可预见的，比如文件不存在、网络超时等，它们不是需要打断整个调用栈的“灾难”，而是业务逻辑中必须面对的情况。因此，Go采用多返回值，让函数同时返回结果和一个error：
- 每次调用后检查
if err != nil，强制开发者直面错误，避免了异常机制下错误被层层上抛却无人处理的风险。 - 错误像普通变量一样传递和处理，代码的执行路径是线性的，从上到下阅读即可理解流程，不会因为catch块而产生跳跃，极大提升了可读性和可维护性。
- 这与c语言用返回码处理错误的思想一脉相承，但Go的
error接口提供了更优雅的统一抽象。
panic不是常规错误处理手段
Go并非完全没有异常机制，它提供了panic和recover。但这套机制有明确的定位：
-
panic用于表示真正意料之外、程序无法继续正常运行的严重错误，例如数组越界、空指针解引用等。它的作用是快速崩溃，终止不安全的状态。 -
recover是一个特殊的内置函数，只能在defer延迟调用中使用，用来捕获并停止panic的传播。它通常只在极少数场景下使用，比如构建服务器框架时防止某个请求的意外崩溃导致整个服务退出。 - 将真正的“异常”（panic）转化为可处理的“错误”（error）是一种常见模式，最终对外暴露的依然是标准的
error接口。
设计哲学：简洁、明确、可控
Go的设计者认为，传统的异常机制虽然强大，但也引入了复杂性：
立即学习“go语言免费学习笔记（深入）”；
- 开发人员必须时刻警惕每个函数调用都可能抛出未声明的异常，导致心理负担和代码审查困难。
- 大量的try/catch会割裂业务逻辑，使核心代码淹没在错误处理的样板代码中。
- 错误的传播路径不透明，难以静态分析。
Go选择了一条更朴素的道路：用一点语法上的冗长（写更多的if err != nil），换取了整体代码的清晰、简单和对执行流程的完全掌控。基本上就这些。