解决PHP在Linux下curl发送POST请求返回400的问题 作者: liesauer 时间: 2020-03-22 分类: 开发 4 条评论 ## 问题描述 代码部署到服务器后，curl发送POST请求，返回400状态码，经本地测试发现无法复现。 ## 问题排查 排查个鬼，玄学得一批，查到头皮发麻。于是乎，又到了万能的百度出手了，经过了大量查阅，终于发现了问题所在。问题出在于在Linux下如果发送空请求参数的时候不能使用`curl_setopt($ch, CURLOPT_POST, true)`来设置为POST请求，如果确有需要，可以用`curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'POST')`代替，但是如果我们使用别人提供的类库进行请求咋办呢，这时候只能随便加个参数上去，不要发送空请求就好了，比如随便加个`t=xxxxxx`。
暴力切换clang++的gcc版本 作者: liesauer 时间: 2020-03-19 分类: 开发 评论 ## 当前已安装的gcc版本 ```shell liesauer@LA-Tower:/mnt/o/Projects/core-setup$ clang++-3.9 -v clang version 3.9.1-19ubuntu1 (tags/RELEASE_391/rc2) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5 Candidate multilib: .;@m64 Selected multilib: .;@m64 ``` ## 常规方式切换 通过网上大量查阅资料，发现都是通过设置环境变量或者传递参数到clang++实现gcc版本切换，但由于我是使用提供的脚本进行编译，各种环境变量都被脚本控制得死死的，而且编译前都要进行`git reset --hard HEAD`，所以修改编译脚本也不现实。 - 阅读剩余部分 -
如何使用Travis CI来做GitHub的Release自动发布 作者: liesauer 时间: 2020-02-13 分类: 开发 评论 ## 起因 由于GitHub在国内越来越难访问了，甚至于Release都是托管在亚马逊AWS下，访问起来更是问题了，十几KB甚至几KB的速度已经是惯例了，想上传个Release都得上传半天。其实这个上传脚本我很早之前就在用了，近期有空就刚好做成一个傻瓜式自动脚本供给其他的项目用。 ## 食用演示 注意，本文不会对`git` `github` `travis-ci` `yaml`等相关知识做过多解释，需要读者有一定的基础。 ### 创建仓库 首先我们新建一个测试演示的空仓库  - 阅读剩余部分 -
记抖音爬虫中所遇到的坑 作者: liesauer 时间: 2020-01-08 分类: 默认分类 评论 ## 常规问题 一些常规问题在此就不做记录了，比如怎么获取某加密参数、需要访问哪些接口、哪些接口无水印等等就不说了，善用搜索引擎。 ## 坑一：判断接口是否成功 由于接口的原因，接口返回的`aweme_list`列表有可能是空的且`status_code`还为`0`，不能通过这两个数据判断接口是否调用成功，可使用`min_cursor`和`max_cursor`判断，当请求成功时，返回的数据必有这两个字段，必然不是`null`或者`undefined`。 ## 坑二：判断是否还有更多 还是接口的问题，当请求失败时，返回的`has_more`还是为`true`，需要通过判断接口是否成功以及`has_more`共同判断，调用成功并且`has_more`为`true`才是真正的还有更多，否则稍有不慎就会出现死循环抓取。 - 阅读剩余部分 -
axios较完美的超时以及重试失败解决方案 作者: liesauer 时间: 2020-01-06 分类: 默认分类 评论 ## 代码引用 1. [Retry Solution From KyleRoss@github](https://github.com/axios/axios/issues/164#issuecomment-327837467 "Retry Solution From KyleRoss@github") 2. [Timeout Solution From aarcangeli@github](https://github.com/axios/axios/issues/2143#issuecomment-495994940 "Timeout Solution From aarcangeli@github") ## axios 的 retry 解决方案 见：[Retry Solution From KyleRoss@github](https://github.com/axios/axios/issues/164#issuecomment-327837467 "Retry Solution From KyleRoss@github") ## axios 的 timeout 问题 在`0.18.0`版本中`axios`的`timeout`并没有被正确实现导致有可能在弱网环境或不稳定环境或代理环境下`timeout`无效、程序卡住的情况（见：[Axios will not timeout on idle sockets](https://github.com/axios/axios/issues/2143 "Axios will not timeout on idle sockets")），虽然这问题在`0.19.0`版本中修复了，但是`0.19.0`版本中对配置合并的规则的阻断性更新导致我们的重试失败解决方案失效（见：[Axios 0.19.0 issue](https://github.com/axios/axios/issues/2397 "Axios 0.19.0 issue")），所以我们无法升级到`0.19.0`来解决这个问题。 - 阅读剩余部分 -