先介紹一下使用場景，ESP8266進入AP模式進行監聽，瀏覽器發起GET請求，然後WiFi模塊進入透傳模式回覆，最後主動斷開連接。
因爲直接使用的串口助手，8266也設置的回傳模式，所以這裏可以看到相應的返回，出現了busy s...
那麼這個busy對我們的實際操作有沒有影響呢，結合我們瀏覽器顯示的內容：
和實際發送的報文：
HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Wed, 08 Apr 2020 09:29:22 GMT
Content-Type: text/plain
Content-Length: 265
Connection: keep-alive
Last-Modified: Tue, 18 Sep 2018 03:55:48 GMT
Accept-Ranges: bytes
RT-Thread is an open source IoT operating system from China, which has strong scalability: from a tiny kernel running on a tiny core, for example ARM Cortex-M0, or Cortex-M3/4/7, to a rich feature system running on MIPS32, ARM Cortex-A8, ARM Cortex-A9 DualCore etc.
可以發現顯示的內容中，最後9個字符 Core etc.並沒有在網站上顯示，而且我們知道，esp8266在進入透傳模式的時候，是不會回顯的，而這裏可以看到在>的後面出現了一個沒有顯示的字符，這說明，實際的數據已經傳輸完了，這幾個字符是傳輸完了再補上去的。
清空統計我們再發一次：
實際發送長度爲491，而我們統計的長度爲482，剛好差了9個字節。
再仔細觀察報文，發現一共有9個換行！
那麼個人猜測，是由於串口助手發送的換行符，會自動把換行‘\n’轉換成\r\n，造成了數據長度的增加，此時把透傳發送指令從AT+CIPSEND=0,482改成AT+CIPSEND=0,491：
不僅沒有出現busy，數據發送也成功了。
在分析數據的過程中，因爲頁面內顯示內容(RT-Thread is an open source IoT operating system from China, which has strong scalability: from a tiny kernel running on a tiny core, for example ARM Cortex-M0, or Cortex-M3/4/7, to a rich feature system running on MIPS32, ARM Cortex-A8, ARM Cortex-A9 Dual)的長度剛好是256bytes，考慮到會不會是因爲某些原因，導致了傳輸過程中只能傳輸255+1個字節，還去搜索了一波關於HTTP和GET的相關知識，發現好像並不是，最後還是通過觀察串口助手的數據統計發現的。
雖然在程序中，我們自己寫的發送函數一般是不會經過轉義的，但在使用一些第三方庫的時候，比如rt-thread的rt_kprintf，默認勾選流輸出的時候，就會自動把\n轉成\r\n，上次在使用rt-thread+lan8720a+lwip試玩webclient組件的時候，也遇到過後面9bytes顯示不全的問題，而這次使用的是esp8266，並沒有連接到家裏的路由器，甚至使用的電腦都不是同一臺……除了數據包內容的原因，可能就再也找不到別的原因了（博主曾經看到過esp8266刷AT固件使用的lwip協議棧，如果沒找出這個轉義的問題，可能就要準備去查lwip源碼了T_T）。