HTTP 无状态 vs 有状态协议 🎯
好的，先画个直观对比图让你秒懂！
好，图有了，现在讲清楚核心概念 👇
无状态 的意思很简单：协议本身不记忆任何上下文。HTTP 每次请求/响应完成后，服务器就把你"忘干净了"。下一次请求，你是谁？第几次来？上次干了啥？它一概不知。请求与请求之间，零关联。
有状态 协议则相反：通信双方在整个会话期间共同维护一份"连接状态"，这份状态记录了序列号、窗口大小、对方确认到哪里了、现在处于什么阶段......双方得时刻对齐这些信息，连接才能正常工作。
典型的有状态协议举几个：
TCP 是最典型的例子，三次握手 → 数据传输 → 四次挥手，整个生命周期都有状态机在跑。FTP 也是，你登录后服务器记住了你的身份和当前目录。SSH 同理，整个 session 的加密上下文、认证状态都是持久维护的。WebSocket 也算，一旦握手升级，连接就变成全双工有状态的了------这也是它比普通 HTTP 轮询高效的原因之一。
💡 一个很妙的类比：无状态协议像是便利店收银员，每个顾客结完账就忘了，下个人来又是新的开始；有状态协议像是银行柜员，你一坐下来，他就打开了你的账户，整个业务办完之前，状态一直保持。
顺带说一句很有意思的工程现实：HTTP 虽然本身无状态，但我们每天用的 Web 应用都是"有状态"的 ------登录态、购物车、用户偏好------这些是靠 Cookie / Session / JWT / LocalStorage 这类应用层机制 来模拟的，不是协议原生支持的。所以 HTTP 的无状态性是一种设计选择，换来的是极强的可扩展性（任何服务器都能处理任何请求，无需亲和性），代价是应用层要自己管理状态。
这也是为什么 RESTful API 设计里，"无状态"是一条核心约束------每个请求必须携带足够的信息让服务端处理，不能依赖服务端记住你上一次干了什么。