內網訪問排版核料詳情功能，用戶反饋要等十幾秒
?
排查 sql：sql 比較簡單
排查內存計算：arthus trace 類名 方法名? 總耗時2s
排查頁面渲染是否緩慢：F12 查看接口 等待服務器響應 20s 下載時間 30s, 故不考慮渲染問題
排查請求響應日志打印：關閉請求響應日志攔截器 問題依然存在
本地還原數據 idea postman單獨調接口：返回 12M ，耗時依然存在啊，跟頁面無關
排查序列化問題：接口方法返回值改成 String, 把響應結果使用 ObjectMapper序列化成 json字符串（獲取容器的 objectMapper） 不存在耗時，跟序列化貌似無關
排查框架問題，把接口方法復制到新的 springboot項目中，不存在問題，斷定框架存在問題
排查攔截器、或過濾器問題：從 controller 方法的 return開始 debug ,經過層層 debug, 在RequestResponseBodyAdviceChain..beforeBodyWrite 發現長時間停頓，再次 debug 發現easy-trans攔截器，項目中開啟了全局掃描，關閉easy-trans全局掃描：
easy-trans: is-enable-global: false
中間猜測有什么特殊注解，沒想到沒有注解光trans掃描就很耗時（項目體量大了，注解都敢用：接口日志注解。spring創建的bean多了，啟動慢，@Data編譯也慢）數據量、體量一大，什么問題都放大
問題解決
收獲：使用arthus查看各個業務方法的耗時，不需要添加日志來實現
解決問題思路：不懂原理，了解信息不夠，通過猜想，拼接基礎知識，不斷各種試驗（歇一歇停一停就會有新思路），找到一個線索后，逐漸挖掘，一步步接近，拼接運氣：easy-tran攔截器正好在controller方法結束時就調用，如果埋藏在各個攔截器中，通過debug很難找出來，springmvc源碼不好debug。
?
新收獲：RestController可直接返回string（手動序列化再返回），前端依然可以兼容
如果是string，springmvc 的converter發現string直接發送，不再json序列化
?
?
?
)
