学习不是换赛道，是把回路拉长

01 / 控制 × 软件

从传递函数到 API，我开始看到相似的边界

自动控制原理最初给我的感觉是公式很多。后来做小项目，我才明白框图真正有用的地方：它强迫我先说清楚一个模块接收什么、内部改变了什么、最后输出什么。

写软件接口时，这种思路意外地熟悉。一个设备状态接口不该把所有内部变量都倒出来，就像一个控制模块不需要向外暴露每个中间节点。稳定的边界，比“现在能拿到更多数据”更重要。

把复杂系统切成可验证的小块，是控制课和编程课同时教会我的事。

我现在会先问三个问题

输入是否明确？状态由谁拥有？失败之后，调用方能否判断下一步？这三个问题并不能自动写出好代码，却能让我少做很多只在演示时成立的实现。

02 / Linux × 网络

第一次把服务放到公网之后

我第一次看到自己的页面通过公网 IP 打开时，注意力全在“终于成功”。过了几天，真正的问题才出现：服务重启后是否会自动恢复，日志会不会无限增长，数据库有没有备份，下载文件是否可能被替换。

于是一次简单部署慢慢长出完整的边界：Caddy 只负责入口，容器负责运行环境，数据库不开放公网端口，发布文件必须记录哈希，修改配置前先验证再替换。

# 我现在更愿意先做检查，再做切换
caddy validate --config /etc/caddy/Caddyfile
docker compose config -q
docker compose up -d

服务器教给我的不是几条命令，而是一个习惯：把“失败时会发生什么”也当成设计的一部分。

03 / 通信 × 调试

一根串口线里的协议课

设备调试最容易让人着急的时刻，是同一条命令有时成功、有时没有回应。最早我会立刻重发，后来才逐渐拆开问题：数据有没有发出、帧是否完整、序号是否匹配、设备正处在哪个状态、超时是否足够。

“重试”不是万能答案。没有状态清理的重试，可能让双方理解得更不一致；没有上限的重试，只会把故障拖得更久。协议应该让错误可见，也应该为退出和恢复留出路径。

调试记录比记忆可靠

我开始给关键请求记录时间、方向、操作码、序号和结果。一次失败的日志可能当时看不懂，但它保留了继续分析的机会。对学生项目来说，这已经是很划算的工程习惯。