@sutking 苦荞茶是可以嚼一嚼吃掉的

@wowo243

可以试试苦荞茶，也很香，泡软的麦粒还能吃，已经代替大麦茶

椅子最低，而且电脑屏幕要加高

电源一块钱一瓦哦，确定不要显卡的话 300W 足够了，参考 http://outervision.com/power-supply-calculator

ssd 尽量 200G 以上的，知道你只放系统和软件，但 ssd 的容量和性能是正相关的……咸鱼水太深，建议 CPU 淘宝散片，其它二手东自营……贵那点钱就当是付个保修

@dodo20120 常用的不一样的也就是圆括号和&&了吧， bash 脚本还是可以直接运行的嘛，反正没感觉不习惯

老东家用 svn 的时候我坚持 git-svn ，治了几次灾难性的分支事故以后，复杂的分支合并就都找我处理了……

fish 秒开，而且不需要什么配置开箱即用

当然，别装 oh-my-fish

还以为是讨论海淘的…

这样说来好像日常黑培训班的时候都没人黑 java 培训班？

生产环境装桌面版的 windows ？这真怪不上微软……

虽然我也不喜欢微软现在 beta 版当正式版的作风

简单研究过 jwt 。个人不建议用 jwt 作 session 用途。原因基本和你的纠结一样， jwt 最大的好处就是把数据带到前端去转了一圈，从而能实现无状态服务端，但 session 这件事天生就是关于维持状态的，和 jwt 是矛盾的。有状态的服务直接发 uuid 作 session key 就好

另外 jwt 之前很多开源实现暴露过致命漏洞（客户端可以直接构造加密方式为不加密的 token 通过校验）这也让我对 jwt 的影响分大减，说白了 jwt 就是参数头+body 的一个约定而已，和自己定协议唯一的区别就是他开源，有三方库，但这些库的质量如果没保证的话，还不如自己定协议靠谱。毕竟自己写代码出 bug 那是自己水平不够测试不严，用三方库出 bug 那完全是吃苍蝇

建议阅读：

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

https://github.com/Kapeli/Dash-iOS/blob/4884835117038fad072afc99a0cbbb4f3fa474fa/Dash/DHDBResult.m#L561

所以这里有一行无法直视的代码

alfred +1

查问题要先要分解，或者说控制变量，这里首先应该按照 http 协议划分一下，是 js 发出去的包异常还是 php 收到的包解析异常？如果是 JS 的话，是原生 JS 的问题还是 jQuery 封装的问题？ PHP 侧同理

浏览器里面看一下请求包， chrome 的话还有 copy as curl 都是你的伙伴

专注不一定代表质量或者效率高吧，我都是高兴的时候才写代码，不高兴的时候找产品测试运维撕逼的，提高效率就是选择合适的时间做合适的事情。白天有各种会有 bug 有问题要查，代码“下班”后再写是正常的吧

@hujianxin ES6 并没有取代多少 lodash 的东西吧

request 用惯了，顺便 promise 一直用的 bluebird 也用惯了

npm init -y
npm i -S request bluebird cheerio

各种小脚本的默认起手式

顺便数据复杂的话再来个 lodash