1. 先把定位说清楚h11 解决的到底是什么问题第一次接触 h11 的时候我把它当成又一个 HTTP 客户端库结果翻完文档才发现方向完全错了。它既不是 requests 那种“发个请求拿个响应”的封装也不是 Flask/FastAPI 那种带路由和中间件的框架更不是 asyncio 里现成的高性能服务器。它做的事情只有一件把 HTTP/1.1 这套字节协议翻译成结构化的 Python 事件再把你想发出去的事件翻译回字节。至于这些字节从 socket 读还是从 TLS 层读是阻塞读还是丢进事件循环里非阻塞读它一概不管。这个边界感是它最大的价值。以前我在一个网关类项目里手写过 HTTP 解析用recv拼缓冲区找\r\n\r\n切头部再根据Content-Length或Transfer-Encoding: chunked决定剩多少 body。写完能跑但一到边界情况就露馅分块长度行带扩展参数、头部被拆成两个 TCP 包、客户端发完请求不等响应就断开、Content-Length和Transfer-Encoding同时出现到底听谁的。这些问题一个个补补到最后代码变成了一座补丁塔谁都不敢动。h11 把这一层彻底接管了。它内部是一个严谨的有限状态机请求和响应各自有明确的状态迁移路径非法迁移直接抛LocalProtocolError或RemoteProtocolError而不是让你带着一个半截坏掉的状态继续往下跑。更关键的是它把“协议正确性”和“IO 调度”这两个关注点硬生生拆开了——你负责喂字节、取字节它负责判断现在该是什么状态、下一条消息该长什么样。做反向代理中间件、协议测试工具、嵌入式设备上的小型 HTTP 服务、教学演示甚至给自家 RPC 框架加一层调试入口这个定位都很舒服。1.1 它和常见库不是替代关系而是分层关系很多人会问都 2020 年代了为什么还要碰 HTTP/1.1 的字节层答案取决于你在哪一层干活。用 requests 的时候你在应用层它帮你处理连接池、重定向、编码、cookie你关心的是业务用 uvicorn Starlette 的时候你在框架层ASGI 协议已经帮你把 HTTP 报文解析成 scope 和 receive/send 的协程接口而当你需要自己实现 ASGI 服务器、自己写代理转发逻辑、或者需要在资源极其受限的环境里跑一个只有几十 KB 内存占用的 HTTP 端点时你就掉到了协议层这一层原本是空白。h11 填的就是这块空白。它不依赖任何第三方库纯 Python单文件级别的实现思路安装之后引入的成本几乎为零。下表是我在实际选型时整理的对照方案抽象层级协议正确性保障依赖复杂度适用场景手写 socket 解析字节层全靠自己边界情况极多无教学、极端受限环境、一次性脚本requests / httpx应用层高但只覆盖客户端中等业务调用外部接口Web 框架内置服务器框架层高较重常规 Web 服务h11协议层高状态机强制约束极轻代理、网关、协议工具、自定义服务器选 h11 的典型信号是你发现自己在recv之后手动 split\r\n或者你需要精确控制发出去的每一个头部、每一个字节的顺序而框架不给你这个口子。1.2 状态机思维为什么它比自己写 if-else 稳HTTP/1.1 表面上简单实际上状态耦合很紧。举个例子一个连接上收到请求之后服务端必须先回响应头再回响应体最后以EndOfMessage收尾如果响应体用了 chunked收尾还得补一个零长度块。这中间任何一步顺序错了客户端就会挂起或者报错。手写代码时这些顺序约束存在于你的脑子里一旦并发上来、异常分支一多就很容易漏。h11 的做法是把这些约束编码进状态机的迁移表。Connection对象维护两个状态our_state和their_state分别表示本端和对端当前处在什么阶段。取值包括IDLE、SEND_RESPONSE、SEND_BODY、DONE、MUST_CLOSE、CLOSED、MIGHT_SWITCH_PROTOCOL、SWITCHED_PROTOCOL、ERROR这些。你调用send()的时候它会先校验当前状态是否允许发送这个事件不允许就抛LocalProtocolError并附带一句相当清楚的错误信息。这个设计带来的直接好处是错误在发生的那一行就暴露而不是在三个函数之后表现为一个莫名其妙的超时。我在调试一个代理转发 bug 的时候深有体会当时是因为上游返回了 100 Continue 我却没有正确转发h11 直接告诉我状态不对省掉了至少半天的抓包时间。1.3 适合上手的几类真实场景按我的经验下面这几类活儿用 h11 特别顺自研轻量网关需要按请求逐字节转发还要在转发过程中做头部改写、body 采样、流量统计。框架给的钩子往往在解析之后拿不到原始字节顺序。协议一致性问题排查线上偶发某类客户端握手失败需要复现“服务端到底回了什么字节”。用 h11 写个回放工具喂一段抓包字节进去看它吐出什么事件比人眼数\r\n快得多。嵌入式或 CLI 场景一台设备上只需要暴露一个状态查询接口装个完整框架纯属浪费。教学与协议实验想让学生直观看到“一个请求在协议层被拆成了几个事件”h11 的事件序列比任何讲义都直观。反过来说如果你只是要提供一个 REST API老老实实用成熟框架别为了“底层”而底层。工具的价值在于用在对的位置。2. 事件模型拆解一次会话到底发生了什么理解 h11 的关键是理解它的事件类型。它把 HTTP/1.1 的一次完整交互抽象成六个事件客户端和服务端共用同一套定义只是方向相反。搞清楚这六个事件剩下的一切都是围绕它们的收与发。2.1 六类事件构成一次完整会话服务端视角下一次请求-响应循环是这样走的h11.Request包含method、target、headers全部是 bytes。收到它说明请求头已经完整解析出来了。h11.Data请求体的一段。可能出现零次、一次或多次。注意它只是“一段”不代表全部body 大时会切成多块。h11.EndOfMessage请求体结束标记。它可能带headers用于 trailer大多数场景是空的。h11.InformationalResponse1xx 中间响应最常见的是 100 Continue。h11.Response正式响应头。h11.ConnectionClosed连接被对端关闭。发送方向的事件是Response、Data、EndOfMessage、InformationalResponse这几个接收方向是Request、Data、EndOfMessage、ConnectionClosed。这个划分意味着你在写转发逻辑时天然就是“读一个事件、决定怎么处理、可能写一个事件”的循环结构代码写出来非常直白。有一个细节容易被忽略Data事件的data字段长度是不确定的取决于 TCP 分片和内部缓冲策略。所以永远不要假设“收到一个 Data 就等于收到完整 body”必须老老实实累积到EndOfMessage为止。2.2NEED_DATA和PAUSED不是一回事next_event()的返回值里有两个特殊的哨兵值新手极容易混。h11.NEED_DATA的意思是“当前缓冲区里的字节不够判断下一个事件了请再喂点数据进来”你把recv到的字节交给receive_data()然后继续调next_event()就行。它是整个读写循环的节拍器。h11.PAUSED的含义完全不同它表示“当前连接上的消息处理到了一个无法继续的阶段但连接本身没坏”。典型场景是协议升级客户端发了Upgrade头双方约定切换到别的协议此时 h11 把状态置为MIGHT_SWITCH_PROTOCOL剩下的字节不再按 HTTP 解析而是通过conn.trailing_data交给你。如果你把这两个哨兵当成一回事写出来的循环要么死循环要么把升级请求当普通请求处理直接坏掉。提示receive_data(b)是合法的它表示对端关闭了写方向。h11 会据此产出ConnectionClosed事件或者在你还有未完成消息时抛RemoteProtocolError。很多“连接莫名其妙卡住”的问题就是忘了处理 EOF。2.3 字节边界头部和 body 一律用 bytesh11 全程只认 bytes不接受 str。头部的 value 里如果出现非 ASCII 字符你需要在应用层自己做编码按 RFC 一般是 latin-1 或 RFC 5987 的编码形式。这个设计一开始会让人有点别扭写惯了dict的人会本能地想传字符串但它其实是在提醒你HTTP 头本质上是一段字节不是 Unicode 文本字符集转换应该在明确的边界做。头部在 h11 内部用Headers对象承载本质是一个由(name, value)元组组成的列表子类。名字会被规范化为小写这一点在查表时很省心但也意味着你不能依赖原始大小写形式。同名头部允许多次出现这在Set-Cookie上是标准用法取值时要用get_all()拿全部用get()只能拿到第一个——这个坑我踩过一次导致多个 cookie 只下发了一个排查了半天。3. 从零写一个能跑的服务端理论说够了直接上代码。这一节给一个完整可运行的阻塞式服务端用最朴素的 socket 线程模型把 h11 的调用节奏完整走一遍。选阻塞模型不是因为性能好而是因为它把 h11 的调用顺序暴露得最清楚等你看懂了再往异步里搬逻辑一模一样。3.1 环境准备与依赖只需要一个第三方包Python 3.8 以上都行python -m venv venv source venv/bin/activate pip install h11装完之后先做个健康检查确认版本和导入正常import h11 print(h11.__version__) print(h11.Connection, h11.Request, h11.Response)如果你的环境里同时装了别的项目建议用虚拟环境隔离避免不同项目对协议库版本要求冲突。h11 的 API 在 0.x 到 1.x 之间有过签名调整混用版本会出现那种“代码没错但就是跑不通”的怪现象。3.2 完整可运行的阻塞式服务端下面这段可以直接保存成server.py跑起来import socket import threading import h11 HOST 127.0.0.1 PORT 8088 MAX_HEADER_BYTES 64 * 1024 MAX_BODY_BYTES 8 * 1024 * 1024 def build_response(status_code, body, content_typebtext/plain; charsetutf-8): headers [ (bcontent-type, content_type), (bcontent-length, str(len(body)).encode(ascii)), (bserver, bmini-h11), ] out [] out.append(h11.Response(status_codestatus_code, headersheaders)) if body: out.append(h11.Data(databody)) out.append(h11.EndOfMessage()) return out def serve_connection(sock, addr): conn h11.Connection(h11.SERVER) method target None body bytearray() try: while True: event conn.next_event() if event is h11.NEED_DATA: chunk sock.recv(65536) conn.receive_data(chunk) continue if event is h11.PAUSED: # 协议升级或提前响应导致的暂停简单场景直接结束 break if isinstance(event, h11.Request): method, target event.method, event.target body.clear() if len(event.headers) 100: raise h11.RemoteProtocolError(too many headers) elif isinstance(event, h11.Data): body.extend(event.data) if len(body) MAX_BODY_BYTES: for ev in build_response(413, bpayload too large): sock.sendall(conn.send(ev)) break elif isinstance(event, h11.InformationalResponse): # 客户端发来的方向不会出现占位保持分支完整 pass elif isinstance(event, h11.EndOfMessage): payload breceived %s %s with %d bytes\n % ( method, target, len(body) ) for ev in build_response(200, payload): sock.sendall(conn.send(ev)) if conn.our_state is h11.DONE and conn.their_state is h11.DONE: conn.start_next_cycle() else: break elif isinstance(event, h11.ConnectionClosed): break except h11.RemoteProtocolError as exc: # 对端违反协议尽量回一个 400 再关闭 try: for ev in build_response(400, bbad request\n): sock.sendall(conn.send(ev)) except Exception: pass print(f[protocol-error] {addr}: {exc}) except (ConnectionResetError, BrokenPipeError): pass finally: try: sock.shutdown(socket.SHUT_WR) except OSError: pass sock.close() def main(): srv socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.bind((HOST, PORT)) srv.listen(128) print(flistening on {HOST}:{PORT}) while True: client, addr srv.accept() client.settimeout(30) threading.Thread( targetserve_connection, args(client, addr), daemonTrue ).start() if __name__ __main__: main()用curl -v http://127.0.0.1:8088/hello就能看到交互。再试试curl -X POST -d abc http://127.0.0.1:8088/x返回的字节数应该和发送的一致。3.3 逐段拆解关键调用h11.Connection(h11.SERVER)这一行决定了状态机的角色。角色不同同一时刻允许接收和发送的事件就不同。客户端角色等待的是Response服务端角色等待的是Request搞反了会在第一个send就抛错。主循环里的next_event()是唯一的读入口。它把“从缓冲区里切出下一个完整事件”这件事封装起来了包含头部解析、分块解码、长度判断。当它返回NEED_DATA说明现有字节不足以判断必须继续recv。这里有个容易犯的错误有些人图省事在recv之后不判断返回值就直接receive_data(chunk)如果chunk是b对端关闭这个调用其实是有效的会触发关闭流程但如果你的循环条件写的是while chunk:就永远等不到关闭事件了。conn.send(event)返回的是需要写出去的 bytes注意它不会自己写 socket。这是分层设计的直接体现也意味着你可以把返回的字节攒起来批量发送或者先做日志采样再发。返回值是bytes有些场景下用send_with_data_passthrough()更划算它返回一个 bytes 列表遇到Data事件时直接把原始数据透传过去省一次内存拷贝。body 大的时候这个差别挺明显。conn.start_next_cycle()只在双方都处于DONE时才允许调用作用是复位状态机让连接可以处理下一个请求。这就是 HTTP/1.1 的持久连接机制。调用之前务必确认当前这一轮的所有数据和收尾事件都已经发完否则状态机会拒绝并抛错。3.4 客户端方向是对称的写一个客户端逻辑几乎镜像import socket, h11 sock socket.create_connection((127.0.0.1, 8088)) conn h11.Connection(h11.CLIENT) sock.sendall(conn.send(h11.Request( methodbPOST, targetb/echo, headers[ (bhost, b127.0.0.1:8088), (bcontent-type, btext/plain), (bcontent-length, b5), ], ))) sock.sendall(conn.send(h11.Data(databhello))) sock.sendall(conn.send(h11.EndOfMessage())) while True: event conn.next_event() if event is h11.NEED_DATA: conn.receive_data(sock.recv(65536)) continue if isinstance(event, h11.Response): print(status:, event.status_code) elif isinstance(event, h11.Data): print(chunk:, event.data) elif isinstance(event, h11.EndOfMessage): break注意host头必须自己写h11 不会替你补。这是它“只做协议不做语义”的又一处体现。target也是原样的 bytes不做 URL 解析路径和查询串得你自己拆。3.5 Keep-Alive 的收尾逻辑别写错持久连接最容易出错的地方在收尾。一个连接处理完一个请求后是否复用取决于两点双方是否都达到DONE状态以及头部里有没有明确的关闭意图。h11 会把Connection: close反映到状态上转入MUST_CLOSE这时候你就不该再调start_next_cycle()而是发完消息直接关连接。我在一个代理项目里见过这样的写法不管三七二十一响应完就start_next_cycle()结果客户端带Connection: close的时候h11 抛LocalProtocolError被外层一个宽泛的except吞掉表现为连接直接断日志里啥也没有。后来把异常处理收窄问题立刻现形。这个教训是不要把 h11 的协议异常和其他 IO 异常混在一个 except 里它给出的错误信息是这套库里最值钱的部分。4. 分块、长度与头部HTTP/1.1 真正的复杂处头部解析看着简单实际上 HTTP/1.1 里绝大多数互操作问题都集中在这几十行字节上。h11 替你挡住了大部分但你需要知道它挡了什么才能在出问题时判断该往哪查。4.1Transfer-Encoding与Content-Length谁说了算这是协议层最经典的歧义点。一个请求同时带Content-Length: 10和Transfer-Encoding: chunked不同实现可能做出不同判断一方按 10 字节读、另一方按分块读中间的代理就会把多余字节当成下一个请求形成请求边界错乱。这类问题在生产环境里排查起来极其痛苦因为从单个服务看日志一切正常。h11 的处理方式是严格拒绝同时出现两种长度指示或者出现多个不同值的Content-Length直接抛RemoteProtocolError连接终止。这个选择是有代价的偶尔会遇到某个老旧客户端因此被拒但从安全角度这是正确的默认值。如果确实需要兼容正确做法是在更外层做前置归一化而不是放松协议库的校验。下面这张表是我整理的长度判定规则照着看不会错头部组合h11 行为你该做什么只有Content-Length按值读取定长 body校验上限防止超大 body只有Transfer-Encoding: chunked逐块解码Data事件不带分块元信息正常累积到EndOfMessage两者同时存在抛RemoteProtocolError记录日志必要时在网关层拒绝多个不同值的Content-Length抛RemoteProtocolError同上两者都没有但有 body视为无 body多余字节成为下一个请求严格模式下应直接关闭4.2 头部大小、数量与慢速连接h11 本身不限制头部总量它只负责解析。这意味着如果对端慢吞吞地一次发一个字节你的recv循环会一直转缓冲区一直涨。这类慢速写入是资源耗尽型问题的常见来源防御必须放在你的代码里而不是指望协议库。我的做法是双阈值单次会话的累计接收字节数设上限比如 64KB 头部 8MB body同时给 socket 设读超时。示例代码里client.settimeout(30)和MAX_BODY_BYTES就是干这个的。头部数量也要限虽然 h11 会维护列表但成千上万个头部同样能把内存吃掉。注意超时触发的是socket.timeout它和 h11 的协议异常是两回事。捕获时要分开处理前者直接关连接即可后者最好能记录下具体是哪个头部或哪个状态出的问题。4.3Expect: 100-continue的转发客户端发大 body 前常会带Expect: 100-continue等服务端点头再发。服务端如果不回 100 而是直接回最终响应客户端应该停止发送 body。h11 用InformationalResponse事件表达 1xx你在转发时要把这个事件原样传下去不能忽略。忽略的后果是客户端一直等连接挂起到超时。我在调试一个上传接口时遇到过前端上传小文件正常大文件必卡最后定位到中间层把 100 响应吞了。修法很简单收到InformationalResponse就send()出去别做任何过滤。唯一需要注意的是1xx 响应不能带 body也不该触发EndOfMessage状态机会自己管。4.4 HTTP/1.0 与头部兼容性老客户端可能发 HTTP/1.0 请求默认不带Host头也不默认持久连接。h11 的Request事件里有http_version字段值是b1.0或b1.1。你如果要在响应里回http_version照抄请求的版本是最稳的虽然实践中回 1.1 大多数客户端也能接受。对于 1.0 请求如果没带Connection: keep-alive响应完就该关连接。判断逻辑别写在业务代码里散落各处集中到一个函数里否则迟早漏。5. 排查清单那些我踩过的坑协议层的 bug 有个共同特点——现象离原因很远。下面这些是实际遇到过并整理下来的按现象归类出问题时可以直接对照。5.1 典型报错对照表现象可能原因定位手段处理方式抛LocalProtocolError: cant send Data when in state DONE响应已收尾还继续发数据打印our_state和their_state检查循环里是否漏了状态判断抛RemoteProtocolError: illegal header name对端头部含非法字符抓包看原始字节记录并回 400不要试图修复连接一直挂起不返回没处理NEED_DATA或忘了receive_data(b)加日志看next_event返回值补全 EOF 分支只收到部分 body把单个Data当成完整 body打印每次Data长度累积到EndOfMessage第二个请求失败忘了start_next_cycle()看状态是否停在DONE在合适时机复位响应乱码头部 value 用了 str检查类型统一转 bytes5.2 字节级调试的几把小工具第一条经验把recv到的原始字节打出来用repr()而不是直接 print。控制字符、\r\n、多余空格只有在repr下才看得见。我见过一次“客户端发的头部看着完全正常但就是解析失败”repr一打发现行尾是\n而不是\r\n。第二条写一个回放函数把抓到的字节序列按分片喂给Connection观察事件流。这比对着抓包工具逐字节数快得多def replay(raw, roleh11.SERVER): conn h11.Connection(role) for i in range(0, len(raw), 1): # 故意按单字节喂模拟最坏分片 conn.receive_data(raw[i:i1]) while True: ev conn.next_event() if ev in (h11.NEED_DATA, h11.PAUSED): break print(ev)按单字节喂是最狠的测试能一次性暴露所有“假设了某个字节一定在同一个包里”的错误。这个习惯我从写协议代码开始保留到现在几乎所有分片相关的 bug 都能在开发阶段被它拦下来。5.3 拷贝、缓冲与背压h11 内部维护一个接收缓冲区receive_data会把字节追加进去next_event消费掉已解析的部分。如果你一次recv很小调用次数会爆炸一次recv很大内存占用会上去。经验值是 64KB 左右比较平衡配合 TCP 的默认窗口大小既不会频繁唤醒也不至于堆积。发送侧有个小优化send_with_data_passthrough(event)在遇到Data事件时不会复制数据而是把原始 bytes 直接放进返回列表。做代理转发时body 往往原样透传用这个接口能省掉一次完整的 body 拷贝。body 越大收益越明显几百 KB 级别的请求能看出差别。背压这件事得自己管。h11 不知道对端读得慢不慢你如果无脑send不停写socket 缓冲区满了就会阻塞阻塞模型或者堆积在内存里非阻塞模型。转发场景里正确的做法是只在确认写空之后才继续从上游读形成自然的背压传导。6. 塞进现有系统的几种姿势前面写的是独立小服务但真实项目里 h11 更多是作为一块积木嵌进去。这一节讲三种集成方式都是我在实际项目里用过的。6.1 在异步框架里驱动状态机把阻塞 socket 换成asyncio的StreamReader/StreamWriter或loop.sock_recv循环结构完全不用变。唯一要做的是把recv换成await reader.read(65536)把sendall换成writer.write()加await writer.drain()。状态机本身不关心 IO 是不是异步的这正是它分层的红利。有一个细节值得注意drain()的位置要放对。如果你在发完响应头和 body 之后忘了drain写缓冲会一直涨。正确做法是每批send出来的字节 append 到writer之后调一次让事件循环有机会在背压时挂起协程。6.2 与 TLS、协议升级的边界TLS 层完全在 h11 之外。你在ssl.SSLSocket或asyncio的 TLS 流上读写拿到的明文交给receive_data发出去的 bytes 交给 TLS 层加密。这层解耦很干净唯一要小心的是 TLS 关闭和 HTTP 关闭的顺序先走完 HTTP 的收尾再优雅关闭 TLS否则对端可能收到RST而不是正常的close_notify。协议升级Upgrade头需要特殊处理。h11 在检测到升级意图后会把状态推进到MIGHT_SWITCH_PROTOCOL此时next_event()返回PAUSED剩下的字节通过conn.trailing_data取。必须第一时间把trailing_data取走并转交给新协议处理晚一步就可能丢字节——因为那些字节已经被从缓冲区里摘出来了不会再有第二次机会。6.3 用字节回放做回归测试协议层的功能测试最好不要一上来就连真的 socket。我的做法是把测试用例写成“输入字节序列 → 期望事件序列”的形式直接对Connection做断言。这样测试跑得飞快而且不受网络环境影响。def test_simple_get(): conn h11.Connection(h11.SERVER) conn.receive_data(bGET / HTTP/1.1\r\nHost: x\r\n\r\n) assert isinstance(conn.next_event(), h11.Request) assert isinstance(conn.next_event(), h11.EndOfMessage)边界用例才需要字节拼接比如“头部被拆成两个包”、“分块长度行带扩展”、“同时带两种长度头”。这些用例一两百个跑下来也就几百毫秒比任何集成测试都划算。等多字节分片、长度歧义、HTTP/1.0 兼容这些用例都覆盖了再往上做端到端测试心里就踏实了。还有一个小技巧把你线上抓到的真实请求字节脱敏之后存成 fixture定期喂给状态机跑一遍。协议库升级、你自己封装层改动的时候这套回放能第一时间告诉你有没有破坏兼容性。我维护的一批 fixture 里最老的一条是三年前的救过两次。7. 我个人的几点使用体会用这套东西断断续续几年最深的感受是它把“协议正确性”这件事从我的职责范围里拿走了但又没有把控制权拿走。框架给的是便利代价是你要按它的约定来手写给的是自由代价是无穷的边界情况。h11 恰好落在中间状态机保证不会出现协议级错误事件模型又让你能精确控制每一个字节的去向。如果非要说一个最容易忽视的点我会选异常分类。LocalProtocolError意味着你的代码调用顺序有问题属于 bug应该让它冒出来RemoteProtocolError意味着对方发的东西不合规属于外部输入应该记录并优雅关闭。把这两类混着处理等于把自己的 bug 和对端的问题糊成一团排查时完全失去方向。另一个建议是别急着上异步。先把阻塞版本写通把事件序列、状态迁移、收尾逻辑都摸熟再去套asyncio的壳改动量其实很小。反过来先啃异步很容易把协程调度的问题和协议状态的问题搅在一起调试起来非常痛苦。我第一个版本就是踩了这个坑最后退回去用阻塞模型重写了一遍反而一天就跑通了。最后一个偏实战的建议给每个连接加一个唯一标识把our_state、their_state、最近若干条事件都打进结构化日志。协议层的偶发问题往往只在特定分片模式下出现没有这条完整轨迹复现基本靠运气。有了它大部分“偶发”能在一两天内定位到具体是哪个状态迁移没处理好。