# 语言哲学：保证由谁承担

学习目标：用同一次需求变化，区分接口暴露的约定、工具能够检查的性质和调用者仍需承担的责任。

前置阅读与范围：先读字符串转端口号与将报告写入不同目标，理解输入校验、返回失败和写入能力的用途即可。本篇不要求先掌握类型理论，也不新增代码实作；分析限于这些示例，不据此给语言排名。

# 从两个具体问题出发

字符串转端口号要求外部文本满足配置契约；将报告写入不同目标要求调用方提供可写目标。

下面把机制事实与设计分析分开：机制事实由相邻的官方资料支撑；“是否值得”“成本在哪里”等判断是对本例的分析，不是设计者原话，也不把某一种写法概括成整门语言的唯一理念。

# 编译器知道什么

编译器可以检查一个参数是不是字符串，或者对象是否提供规定的方法。但“字符串表示合法端口”还需要解析和业务校验。

例如，Rust 的 u16 可以限制表示范围，却仍然允许 0；参见 u16 的最小值。TypeScript 的 number 也没有单独编码端口范围；参见 TypeScript 的常用类型。

设计分析：若业务需要在多层调用中保持不变量，可以考虑私有构造加校验函数等封装；是否值得这样做取决于重复校验和误用的成本。“静态类型”并不自动等于“业务输入已经有效”。外部数据进入系统时，任何语言都要决定如何建立可信边界。

# 失败暴露不等于处理正确

本知识库的端口示例选择了几种不同方式：

示例	调用方看到的接口	阅读时应追问
Rust	Result	哪些错误需要传播或处理？
Go	值与 error	是否先检查错误再使用值？
Java、Kotlin、Python、JS/TS	普通返回值，失败抛异常；Java 的受检异常另有声明规则	哪一层捕获，如何向用户说明？
C++	optional	只知道失败是否够用？

这些是示例选择，不是语言能力边界。Java 也能设计结果对象，Kotlin 也能返回可空值，C++ 也能抛异常。

机制事实：Rust 的 Result表示成功或失败；Go 的 error是接口类型，错误值不会自动触发异常传播；Java 对受检异常要求捕获或声明传播。端口例子的 Java 输入校验异常属于非受检异常，不能与报告输出中声明的 IOException 混为一谈。

设计分析：失败出现在签名中，不等于调用者正确处理了失败。应分三层看：

接口暴露：Result、error 或 throws IOException 让读者看到某种失败通道；具体错误含义仍可能需要文档说明。
静态工具：编译器或检查工具能检查一部分使用约束，但检查范围取决于语言机制和工具配置。例如 Rust 对未使用的 Result 通常给出警告，Java 的捕获或声明规则则是编译期约束；它们不是同一种强度的保证。
调用者责任：调用者仍可能忽略错误、直接中止、捕获后不作处理，或传播给没有恢复策略的上层。检查通过并不能证明业务恢复、用户提示或数据完整性正确。

未使用值的诊断规则参见 Rust unused_must_use。本例用 ? 传播 Rust 写入错误、用 Go 的 if err != nil 检查错误、让 Java/Python 的失败继续传播；这些是可见的调用策略，不是“已解决所有失败”的证明。

异常可以让成功路径保持连贯，显式结果也可以让失败分支更醒目；两者都需要设计传播边界，不能只按成功路径的行数比较易用性。

# 用新增文件输出目标比较修改成本

统一变化是：保留原有内存验证，再新增一个文件输出调用。报告文本不变，报告函数不变，文件由调用方创建和管理。下面不重复报告输出的代码，而是逐项区分修改范围、声明成本、反馈时机、语义约定。Python 的真实文件调用已在该篇给出，其他三种在这里仅分析标准库目标的接入方式。

# Rust

机制事实：std::fs::File实现 Write，可以传给本例的 &mut impl Write 参数；File 的析构会关闭文件，但析构中的关闭错误会被忽略。相关约束见 Write。

设计分析：修改发生在调用方的文件创建、传入和错误传播处，write_report 不变。使用标准库 File 无需自定义 trait 或适配层，已有类型已经支付了实现声明成本。不满足 Write 的实参会在编译时得到反馈，路径或写入失败则要在运行时处理。调用者仍需明确输出字节、部分写入后的策略以及是否要求持久化；不能把 Result 或离开作用域等同于所有 I/O 失败都已被观察。若换成自行定义的目标，则需要相应的 trait 实现，这是不同于复用 File 的额外成本。

# Go

机制事实：*os.File具有满足 io.Writer 的方法集，无需显式声明实现关系；io.Writer还约定短写时必须返回非空错误。文件的 Close本身也返回错误。

设计分析：修改在调用方增加创建文件、传入文件和关闭操作，writeReport 不变。标准库文件无需包装；自定义目标也只需提供兼容方法集，没有 implements 声明，但仍有实现方法及遵守协议的成本。方法集不匹配会在编译时反馈，打开、写入或关闭失败是运行时反馈。报告函数返回写入错误并不能替调用者检查关闭错误，单独写一个延迟关闭调用也不等于检查了其返回值。

# Java

机制事实：Files.newBufferedWriter可以按显式编码创建文件文本写入器，返回的 BufferedWriter 属于 Writer 类型层次；try-with-resources负责自动关闭资源，并规定多异常情况下的传播规则。

设计分析：修改在调用方增加路径、明确 UTF-8 的文件写入器和资源管理块，writeReport 不变。已有类层次免去本次自定义接口成本；若自行实现新的 Writer，则需要显式进入该类型层次并实现其抽象操作。无关类型即使也有同名 write 方法，仍不能直接传给这个参数。类型关系及受检异常的捕获或声明在编译时检查；真正的 I/O 失败发生在运行时。缓冲写入可能在刷新或关闭时才失败，调用者还需决定异常如何报告，不能把 throws IOException 当成恢复方案。

# Python

机制事实：open的文本模式支持显式编码和换行控制，文件对象可以用上下文管理关闭；typing.Protocol可向静态检查工具描述结构化接口，但类型注解本身不执行运行时类型检查。

设计分析：修改在调用方增加临时目录、以 UTF-8 和固定换行规则创建文件、上下文管理以及关闭后的字节断言，write_report 不变。当前函数的 out 未注解，无需继承或实现声明，也没有仅由该参数声明带来的静态能力检查；不兼容调用通常在执行相关路径时反馈。若项目引入协议注解和静态工具，就需要额外维护协议声明。即使工具确认存在 write，调用者仍需确认它接收文本而非字节、失败会如何报告，以及文件是否已刷新关闭。

本例结论：四种写法都能保持报告函数不变。差异不在“谁完全不用修改”，而在已有标准库关系能复用多少、哪些兼容性可以提前反馈、以及哪些语义必须由实现者和调用者共同遵守。一次标准库文件接入不能代表自定义目标、异步流或整门语言的抽象成本。

# 资源归谁管理

报告函数不创建也不关闭目标，是本例选择的职责边界。新增文件目标后，调用者需要负责资源释放，并决定如何观察和处理写入、刷新或关闭失败；不能因为内存目标验证通过，就假定文件调用也一定成功。

垃圾回收讨论的是内存管理，不能直接替代文件和连接的及时释放。Python 官方教程也建议使用 with 管理文件，以便异常发生时仍关闭资源，参见文件对象的使用。Rust 的析构、Java 的资源管理块、Go 的延迟调用和 Python 的上下文管理具有不同的错误观察方式，不能仅凭“都会清理”就视作完全等价。这一问题在错误处理与资源中继续定位，不在本篇扩写为新实作。

# 如何评价一个设计

面对同一需求，可以依次问：

哪些错误会在编译期暴露，哪些必须在运行时验证？
调用者从函数签名能知道什么，还需要读哪些约定？
增加一个实现，需要修改多少已有代码？
失败和资源清理发生在哪一层？
引入的抽象减少了真实重复，还是只让例子看起来更完整？

这些问题比“哪门语言最优雅”更容易得到可检验的答案。本篇的判断限于已经给出的端口解析和报告输出，不推导普遍排名。组装方式与命令见对应实作文章，执行证据见验证记录；本篇不新增代码块，也不声称分析本身构成执行验证。