牵头羊来几分钟就能啃完，你觉得你的水平和羊比如何？

@mcfog 更正一下后面，精确地说，应该是
f.[[Scope]] => DeclarativeEnvironment { ..., outer => Lexical Environment{ a=1 } }

如果你的 console.log(a)旁边有 var x=42，x=42 就是在...位置的

执行（ enter ） function 的时候的过程在这里，确实会新建 execution context

https://www.ecma-international.org/ecma-262/5.1/#sec-10.4.3

注意

> Let localEnv be the result of calling NewDeclarativeEnvironment passing the value of the [[Scope]] internal property of F as the argument.

这里，后续用来创建 context 的 localEnv 这个东西来自于[[Scope]]这个内部属性，然后这个属性是在创建函数的时候绑定的，参考这里

https://www.ecma-international.org/ecma-262/5.1/#sec-13

关注里面关于 Scope 的描述

在执行 foo，return 前，计算 function() {
console.log(a);
}
表达式的值的时候，当前的 lexical environment 也就是包含 var a=1 的东西被记录在这个函数的[[Scope]]内部属性中了，于是后面有
f.[[Scope]] => Lexical Environment{ a=1 }
阻止了 a 被 GC

@across 少复制了“那么今天小编为你介绍……”段落，扣你一个鸡腿 :doge:

我不认为你理解什么是 semver，请看过 https://semver.org 再来聊

@est 我说 restful 能做，又没说建议用 restful 做。

如果你不懂怎么在一个 restful 风格的体系里设计符合 restful 风格的 2fa 也好 captcha 也罢我可以和你讨论一下我的想法，但我觉得你肯定没有兴趣

哦对了，我也不喜欢 restful，但喜不喜欢一门技术和是否理解这门技术的优缺点，还有能否理性地讨论一门技术是三件不一样的事情，希望你不会因此错过一些更有价值或是有趣的技术

@est 可以当然是可以的，虚拟资源虚拟万物即可
DELETE /session/current 或者 /session/:sid

不如何看待，工作那么多年了就没见过纯按标准来的 PATCH 或者 PUT 方法的接口

顺便，楼主你的理解也并不准确，PUT 同样适用于新增

@Aruforce 实际情况有很多的 locality 和 cache 的因素要考虑
比如说操作 123 分别是磁带机上三个不同文件的读写操作，拆三个循环就都是顺序读写，合在一起反而多了大量倒带的耗时，对比内存里的 a--完全不是一个量级的耗时

当然要考虑，但是什么叫多大程度？怎么个设计架构，花多少精力在预备未来的需求变更上这个东西本身就是考虑的结果

推荐 https://github.com/cortesi/modd

# modd.conf
**/*.php {
prep: composer run test
daemon: php bin/server.php
}

@hmzt Sorry，看你的回复我觉得恶心的是你的想法。服务提供方在法律框架范围内提供的 EULA，用户付款前确认的你就说是霸王条款？违规违法滥用被你说成“买了使用权就可以随便用”？还定价有问题客户没问题，那头等舱卖那么贵一般人舍不得坐也是定价问题？ 你买了头等舱，就怎么用是你的事，可以吃榴莲放抖音影响机舱秩序？

我偷人店里的东西是店门锁没锁好，是店里东西卖太贵了我觉得不值？ 偷来的东西又有别人偷走了就是借花献佛令你恶心？

@whwq2012 好好想想值得珍惜的不应该是 p 站和 p 站触手么，反正我一点也不珍惜楼主

没人说我来说：可是楼主你做的接口和网站也是侵犯 pixiv 的，这个事情不是你不收钱你有理或者你搭服务器你有理的

站在 pixiv 视角你和搜图神器没啥区别

@sunnyadamm 那你就让老板知道你每天多少多少时间都花在收拾烂摊子上了没空做别的事儿就行了，周报什么的就如实写上，老板能接受那就是这份工作性质就这样，不能接受找你你再说怎么样子避免这些烂摊子

发（甩）邮（锅）件（扯）呗（皮）

[生产故障] x 月 x 日某某服务器的故障报告
某年某月按领导要求开放 root 权限给谁谁谁，几点几分谁报告了这个服务器出了什么奇怪问题，经排查后确认原因是啥啥啥，发现后如何如何恢复了机器，故障共计耗时多少多少小时，对生产的影响如何如何。建议怎样怎样

抄你的老板，开发的老板，要求给 root 的老板，开发

你火气大就建议以后 root 部署工作让对面开发的老板来做，或者是让对面开发学习 linux 运维基础什么的，反正就是“你们把机器弄挂了老子也没招”；火气不大就建议运维侧这边完善，比如避免 root 部署这件事本身或者 root 部署由开发侧提需求后运维侧操作什么的

你排除的就是最主要的原因

拉分支提交一排 wip，pr 前 squash 成一个按规范写

不过楼主你的这个 commit message 问题不是太长了，而是在没有 issue tracker。应该是 fix #1234 然后自动解析到 issue tracker 里对应内容的 ticket

grpc 现在支持直接以 http 协议暴露，微服务用 go，前面 php 写胶水层，or 你们前端团队够骚让他们用 node 做胶水