断点调试方法：先看你的 package.json 里 build 的脚本怎么写的。然后用 node --inspect-brk 去执行。
比如，如果是 webpack 的话，就 node --inspect-brk ./node_modules/.bin/webpack 参数
通过 node 的 inspect-brk 参数启动后，node 会自动断点断在 webpack 入口的第一行。这时打开 Chrome，随便一个页面打开 devTools，在左上角会出现一个绿色的 Node.JS 图标（在切换手机显示模式按钮的右边），点击后就会自动连接到 node 的 debug，然后进 source 标签下单步执行就行了。

@ChrisFreeMan https://github.com/nodejs/node/tree/master/doc/changelogs

@maloneleo88 没写反，这里的 reg 是正则对象，res 是要匹配的字符串，result 在循环里的每一次循环都存的是一个匹配结果，然后看你需要 result[1]，result[2] 这样去用就行了。如果是要所有结果的话，那就 push 到数组里就行了

1. match 只返回匹配到的第一条结果，其中 [0] 为匹配到的整个字符串，[1] 为第一个括号捕获组，[2] 为第二个括号捕获组，以此类推。
2. js 的正则 /.../ 只能匹配第一个匹配结果，需要匹配所有结果的话，需要添加 g 标识：/.../g 。但是当你添加 g 标识之后，match 函数就只能返回所有匹配到的字符串了，而丢失了捕获组信息。
3. ES2020 新出了个 res.matchAll() 函数，返回一个迭代器，使用 [...res.matchAll(/.../g)] 即可得到和 python 的 findall 类似的结果，但是区别是 [0] 还是匹配到的整个字符串，[1] 才是第一个括号捕获组。但是更推荐的是使用 for (const m of res.matchAll(/.../g)) { ... } 去循环处理每一个匹配结果。
4. 如果执行环境较旧，没有 matchAll 函数的话。js 的正则是一个对象，内部会保存匹配进度信息。正则对象有一个 exec 方法。所以，可以这样来模拟 res.matchAll 的效果：

const reg = /.../g;
let result;
while (result = reg.exec(res)) {
// 处理 result
}

慎用，如果被检测到，会永久封禁网页版登录的。
应该是不会封客户端登录，账号应该还是能正常用的。

之前基于做过一个机器人，给它发个消息，然后它做一些查询处理之类的，然后回复结果。结果用了不到一个月就被封了，网页版拒绝登录，但是客户端正常。

@jinliming2 p22 的地址好像挂了，可以把最前面的 p22 改成 p10

@xioxu 可以试着解析这个地址自动更新：p22-calendars.icloud.com/published/2/RL1JwQQtKFudYOiicAG_adz9DdrozFeZzv5Uyrs4s3gyWobdzL1NZFH-ZHAsTfuAevtnzdqVdYmcRO_Y_dWtxeIdmzUA1TNkAt5RuotJmsg
这个是不知道谁维护的一个日历订阅地址，可以直接添加到手机日历里的，iCalendar 格式的数据

port must be a number conforming to the specified constraints
非标准端口的不行吗？

@XIU2 听说了，仅加密 SNI 的话，握手信息中还是存在很多指纹，所以他们打算把整个 ClientHello 都加密

@liuidetmks TLS 1.3 的 ESNI 还没普及的情况下，你 https 看的啥网站还是可以知道的。

@cairnechen 倒贴钱的是另一家，叫 hCaptcha，Cloudflare 在用的那个，和谷歌的差不多。
我之前用的感觉挺好，但是也有好多人都说国内不好用。

@luckykong 谷歌貌似并没有以自己的地位打压同行吧？没出现过比如你要在 YouTube 投稿就不能在其他平台投稿这种强迫二选一的情况吧？没出现过搜索引擎结果要付费才能被搜索到，并且不准被其他搜索引擎展示吧？
也许在某些情况下会为了利益与其他企业竞争，但至少没有让用户蒙受损失吧？

连国家都告诉你，不能因为一家企业做大了就无脑扣垄断的帽子，一味的打压。

gg 识别 ip 只是一种主动防御机制。要是没有这些防御机制，就会有人专门用这些机场 ip 来刷流量，影响搜索结果的展示排序，或者用这些机场 ip 作为肉鸡来发动网络攻击。如果因此影响到了 gg 的服务，是不是又有人站出来骂 gg 怎么让把全世界的人都拒绝了？

惨，的确是惨。但怪不了 gg，只能怪这个 ip 被人用来干坏事了，只能怪你不能用正常的 ip 来进行访问。
vps 有固定 ip，能自己租用一个 vps 自己搭服务，你自己就可以保证这个 ip 不会被用来干坏事（不注意服务器安全，vps 被入侵那另当别论）。或者如果你能用家庭宽带的 ip 直接访问 gg 的服务……

安全性要求高的，还可以使用 TLS 双向认证的方案。必须在安装了数字证书的浏览器上才可以正常访问。
或者像一些银行之类的是把证书放在物理 U 盾里定期更新，配合 U 盾驱动免去装证书的麻烦。

@Vegetable 既然你提到了 QQ，那你就应该知道，即便是用爱发电出了官方原生的 QQ for Linux，但是做的不用心那还真不如不做，QQ for Linux 做出来就是拿来恶心人的，就是拿来挨骂的。

虽然 WPS 还不至于到 QQ for Linux 那种纯粹恶心人的程度，WPS 在所有国产的 Linux 软件中算是非常优秀的存在了。
但是这样惰性的维护，一堆小问题几年都不修复的，让人处于一种想用又不想用的状态才是最糟糕的。
想用，是他们的确用爱发电，原生支持 Linux，国产能这么良心怎么也得支持一下吧，为国产 Linux 良心软件的良性循环做贡献。
不想用，是里面总是有一堆恶心人的小问题，几年不修复的，但都是那种忍一忍变通一下又能克服的问题，让你没有十足的抛弃它的理由。

@Clouder1 现在市面上看到的 QQ 、微信的 Linux 客户端，都是非腾讯官方开发的，无一例外，要么是封装的 web 版本，要么是用 wine 封装的 windows 版本。
web 版本随时有被封杀的可能（比如 web 版本的微信很多人就是不能登录的），并且 API 太少，体验不佳。
而 wine windows 的版本，体验稍微好一些，但是因为这些都是 32 位软件，需要 wine x86 的兼容层。现在的 Linux 大多都默认仅包含 64 位系统库了，可以单独装 32 位库，但会导致系统非常混乱。（这个可以参考 Steam for Linux 的 Github issue 仓库，因为 steam 不给 Linux 用户出 64 位客户端，导致安装 steam 必须装 32 位依赖库，而很多显卡驱动都不支持 32 位了，导致显卡驱动装不上。已经被骂了快 10 年了，骂到 Mac 和 windows 都有 64 位 steam 客户端了，Linux 还没有）
不过如果是系统预装 32 位库的话，到稍微好一些，QQ 微信 这些应该用不到显卡驱动，不过总归是有 wine 转换层，性能上还是比不过原生应用。

目前我的解决方案也是 wine，但是为了避免 32 位库污染我的系统，所以我是把 32 位 wine 装在 docker 里面用的，然后 x11 的 socket mount 进去。总的来说：能用，仅仅是能用。