其实真的，支持 utf8 变量名是最好的

我倒是支持这种复杂命名直接上中文，比较麻烦的是数据库表名，感觉比较好的办法只能是缩写+留个翻译表

我也想知道。。因为我跟 lz 一个感觉。。。当然也一个行业

为啥会看不懂标题看不懂目的。。

就是想统计一下有裁员的厂子都是干什么的而已啊？

然后为啥给打码了。。

@lynntime 首先需要外接显示器，然后浏览器 ide 终端设全屏，触发角设置上，左手触摸板三指切，右手触发角

使用频率较低的窗口比如微信+qq+企业微信+finder 就堆在桌面上

前段时间也是在 v 站看到人发的

http://utf8everywhere.org/zh-cn

> UTF-8 编码在设计上保证了一个 ASCII 字符或子字符串永远不会匹配到一个多字节编码的字符中间。这在 UTF-16 中也适用。这两个编码中，多字节编码的码位的编码单元会将 MSB 设为 1。

> 此外，你还可以像在简单的字节数组中一样，直接在一个 UTF-8 编码的字符串中搜索 UTF-8 编码的非 ASCII 的子字符串——无需关注码位边界。这要归功于 UTF-8 的另一个设计特点——一个码位编码的起始字节永远不会与其他码位的尾随字节相同。


第一个字节的高位，在 utf8 中可用来判断这个码点编码成的 utf8 字节串有多长，而低位字节为了实现上面说到的设计，区间就不能包括开头字节的值

比如两位，低字节最多到 10111111，如果编码到 11000000，就无法与开头字节区分

我遇到过加载一个 so 内存泄露的问题，dlopen/close 内存是平衡的，但中途调多一个 api 就不平衡了
然后开了 asan 也没发现泄露，查了两天最后发现是 so 会自己 mmap 一块内存自己做内存管理，然后为了保证速度在 deallocate 之后还会预留一块内存以便下次分配加速，这时候 dlclose 它并不会自行 munmap，造成的泄露


我怀疑你遇到的是不是也是 hook 了 allocate/deallocate 造成的问题

半年， = 一学期

一学期学完一门课并且能真的用来写商业代码

自己掂量呗

反正在学校的时候这种人我们一般：“大佬太强了你之前绝对是学过的吧”

上兵伐谋，其次伐交，其次伐兵，其下攻城

上策：干一份想加班加班不想加不加的工作
其次：入职前交流好加班强度，摸清底细防止加班
下策：加班我就调休请假要加班工资
最次：打一架 /仲裁，离职后发帖：某某公司加班过度

好问题 学到了

1 1 1 随缘

hhhhhh


来来来，先举全人类之力， [想出一个值得举全人类之力的 Project]

你会觉得这想法真傻逼

对，你甚至可以期待一下崩坏……

https://www.youtube.com/watch?v=ve3kraPZSWA

街霸，铁拳，苍翼，guilty gear，今年的龙珠斗士

https://en.wikipedia.org/wiki/Evo_2018

token 的作用是一次性凭证

假设一次会话是 S1 -> B -> S2
S1 跟 S2 商定好 token，那么 S2 如果能接到 S1 的 token，证明此会话必有 S1 参与，不是 B 凭空造的，它防止的是 B -> S2 的流程未经 S1 授权，（或者说防止没请求过 S1 的什么 C -> S2 ）（ CSRF token ）

假设一次会话是 B -> S1 -> S2
这时候 S1 向 S2 出示 token，作用是防止 B 绕过 S1 的代理直接请求 S2 得到结果，此时 token 保证 S2 收到的请求一定是 S1 发起的而不是其它的什么服务器或浏览器本身 （ SSRF token ）

这些都是在不考虑信道，只考虑逻辑情况下的额外安全措施，首先信道不安全的话 token 可被窃取盗用那安全性是白搭，但就算信道安全，恶意代码也可能通过各种方式混入到请求中，比如存在 UGC 内容里，或者 XSS 从接受输入的地方混入了代码，token 主要防的是混入的第三方恶意请求

黑科技又不是他自研，我怎么觉得现在信以为真的人就跟轻信什么磁疗红外聊这个药那个药的老人一样

都被商家随意忽悠一下就进去了

剑走偏锋……算其它目录的总大小

@runziimo 比如。。。你发现公司倒闭不发工资没公司肯招人并且辛苦存的 10w 块钱已经只值 1 块钱了。。

看成了“一大堆小朋友”。。。

翻了翻历史发帖……恩 印象没偏差…… lz 你确定要教大一……