错误处理的安全入口不能漏
参数、环境变量和文件内容都是入口。解析端口时我不再直接unwrap()，而是把错误留给调用者处理：
let port: u16 = input.parse().map_err(|_| AppError::InvalidPort)?;错误消息不要回显完整输入，尤其不能包含令牌或路径。测试只断言错误类型和安全的摘要文本。验证也有边界：格式合法不代表调用者有权限，权限检查要放在执行敏感操作之前。
每个入口先做与语义相符的校验
参数解析不只是把字符串转成类型。端口能转成u16，仍要判断是否允许使用；文件路径语法合法，也可能指向工作目录之外；环境变量存在，不代表值来自可信配置。校验应贴近接口语义，明确长度、范围、允许集合和资源归属。
不要试图用一张通用黑名单处理所有输入。路径、SQL、HTML 和 shell 参数的风险来自不同解释器，应分别使用受控路径解析、参数化查询、上下文编码和结构化命令接口。先把输入变成明确类型，再交给后续步骤，比在原字符串上删除几个“危险字符”更可靠。
错误类型要保留失败阶段
底层读取失败、格式错误、权限拒绝和依赖不可用，对调用者意味着不同动作。把所有错误转换成“操作失败”，虽然接口看起来简单，却让上层无法决定是否重试、提示用户修正还是立即停止。错误枚举可以保留阶段与安全的原因，同时通过错误链保存内部诊断上下文。
添加上下文时要描述正在做什么，而不是把整个输入拼进消息。例如记录“读取配置失败”和配置项名称即可，不必带出文件内容。外部响应可以稳定、简洁，内部日志则通过请求标识关联详细阶段。两者面向不同读者，不应该直接共用一段可能含敏感数据的字符串。
panic不适合处理可预期输入
unwrap()与expect()在测试、原型或由代码不变量保证的内部位置有用途，但用户参数、文件和网络响应都可能正常失败。库代码应返回错误，让调用方选择处置；命令行入口再决定退出码和提示。服务进程更不能因为一条格式错误的请求结束整个进程。
如果某个分支理论上不可达，应通过类型和构造函数尽量让不变量可检查，并在断言附近说明前提。依赖“这里永远不会错”却没有证据，会让未来重构把输入错误变成进程崩溃。错误处理的目标不是彻底消灭 panic，而是把可恢复情况留在正常控制流中。
权限检查发生在副作用之前
输入通过格式校验后，还要核对当前身份能否操作目标资源。这个判断不能只在页面或网关做一次；真正写文件、改配置或调用远端服务的边界应再次校验。错误响应不应区分得过细，以免向无权调用者透露某个资源是否存在或内部路径如何组织。
认证信息、密钥和令牌要通过受控方式传入，不出现在命令参数、错误文本或调试输出中。怀疑凭据失效时先停止使用并走轮换流程，不要把完整值打印出来“确认一下”。测试使用虚构凭据与拒绝用例即可验证流程。
重试之前先判断动作状态
网络超时可能发生在请求送达以后。对写入、发布或发送操作，直接重试会产生重复副作用。接口需要稳定的任务标识或幂等约束，并让调用方能查询已有状态。只读请求也要限制重试次数与总截止时间，避免依赖已经变慢时继续增加压力。
测试应覆盖无效格式、越界值、权限不足、依赖超时、日志写入失败和客户端取消。除了断言错误类型，还要确认敏感内容没有出现在返回值与日志里，失败后资源得到释放，状态没有半更新。安全的错误入口不是让所有问题都悄悄消失，而是让系统在拒绝和失败时仍保持边界清楚、信息足够、后果可控。
