背景：公司新項目用的laravel框架，初期無專門的運維，用guzzle封裝的get/post的對外請求方法，請求某個接口的時候，每頁條數per_page超過一定數就會報錯
GuzzleHttp\Exception\RequestException: cURL error 18: transfer closed with outstanding read data remaining (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)
用postman直接請求會返回數據，但是數據不能自動美化格式，用curl方法請求會返回數據+報錯信息。
解決方法：
（只針對此次遇到的問題的解決方法，同樣的報錯可能是不同的原因引起）
服務器nginx，fpm都是用www用戶運行的，設置nginx用戶為www，統一lnmp體系的權限配置：
chown -R www.www /var/lib/nginx/
解決過程：
看報錯信息提示
http://curl.haxx.se/libcurl/c/libcurl-errors.html
CURLE_PARTIAL_FILE (18)
A file transfer was shorter or larger than expected. This happens when the server first reports an expected transfer size, and then delivers data that doesn't match the previously given size.
傳的數據和預期的數據大小不一致，，，
開始只是在項目里用封裝的方法請求看的報錯，用postman看有返回數據，因此最初一直以為是guzzle封裝的方法有問題，傳的請求header不對，花了大量時間測試http頭信息http1.1的keep-alive、content-length、Transfer-Encoding: chunked 等屬性，最后無果。
后來仔細直接用curl命令請求接口，同樣發現里錯誤信息，這才把注意力放在服務器端的配置上，先是估計可能是nginx或者fpm最大傳輸數據量的配置過小，但返回數據最多也沒超過100k，不應該超過配置大小，
然后在百度搜“PHP nginx http 接口返回內容最大值”
https://blog.csdn.net/sakurallj/article/details/51822828
http://www.dewen.net.cn/q/1913
如果PHP返回的內容過大，nginx會把一部分內容先存到文本文件/var/lib/nginx/tmp/fastcgi中，等全部內容都接收完畢后，再一並發送到客戶端。但是nginx的執行用戶沒有nginx下tmp文件的寫權限。
這才去看了下nginx的error_log發現確實有報錯信息。之后統一了lnmp的用戶角色，解決了問題。。。。
2018/12/13 18:41:31 [crit] 30392#0: *380874 open() "/var/lib/nginx/tmp/fastcgi/3/43/0000000433" failed (13: Permission denied) while reading upstream, client: 182.18.28.66, server: , request: "GET /v1/user/list?page=1&perpage=50 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "123.123.123.13:11008”