在 setInterval 外面加一个 console.log ，看看是不是这个 setInterval 被执行了多遍

@justfindu 可以试试删掉之后放一个空 exe 过去替换，让它去调用这个空 exe 去

@alan0liang 那我要是把 Function 也给你包装到最外层的参数里呢
((window, document, Function) => {
//原始的 js 内容原封不动的放在这
})(windowproxy, documentproxy, Functionproxy);

@gstqc
@flyz
其实就算把判断代码加到 js 里，也只是增加了难度而已，对方只要把页面中所有的 js 内容、js 文件做一次中间处理，包装一层，
((window, document) => {
//原始的 js 内容原封不动的放在这
})(windowproxy, documentproxy);
这样不论中间的 js 怎么写、怎么加密，都始终拿不到原始的 window 对象，只能拿到经过包装的版本，这里对方只要更改 location 的实现，让内部 js 获取不到当前的真实 location。

如果你不用 cloudflare 的话，可以把 cloudflare 的 IP 段全 ban 掉： https://www.cloudflare.com/ips/

您好，欢迎使用疯狗输入法🐶

emoji 表情可以正常显示是因为 emoji 表情本质上就是 Unicode 字符，所以几乎所有设备都可以不用特别处理就显示，只要字体支持就行。
而下面那个选表情的框则是以图片的形式插入的，这样实现起来确实就复杂了好多，以至于微信到现在 iOS 最新版也不支持直接在编辑框直接显示表情。

@phy25 https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
关掉页面不会导致 session cookie 失效，关掉浏览器才会。甚至部分浏览器会让 session cookie 永远不失效（上面 MDN 说的）。
而一般会在当前页面增加链接帮助跳转到目标邮箱，防止用户关闭浏览器。

我的一个项目，也算是蹭着完全不热的热点开的，也没有什么宣传，维护也不频繁，两年涨了 200 star，虽说涨的慢，但是每次在首页看到 star 通知，我知道我的项目又帮到了一个人。
维护不频繁是因为项目功能简单，所以自发布第一个版本之后除了改 bug、调优逻辑之外，真的没啥可维护的。偶尔看到 issue 里有比较好的 feature request 也会考虑加进去。
宣传，也就之前在贴吧里看到有人碰到了同样的需求，我就给推荐过我的项目，当时还没破 50 star。现在，我发现我根本不需要自己去宣传，网上搜索我项目的名字，就能搜到一批个人博客在帮我宣传，在 GitHub 项目的访客统计页面，可以看到 CSDN 的某篇文章给我贡献的访客量都上榜了……
相比涨 star，我更想看到涨下载／安装量，因为下载量和安装量才能代表项目真的帮到了多少人。目前由 Google 统计到的可以统计的下载量在 44k 上下波动。
其实吧，star 真的不重要，重要的是项目的价值，是否能真的帮助到某些人。所以我个人也是比较认同在 GitHub 上放全是 md 的笔记类、汇总统计类项目的，因为可以被搜索引擎检索到，在需要的时候能用到，就是有价值了。
但是类似于用 GitHub issue 做评论系统、拿 GitHub 项目（而不是 release ）当 CDN，或是拿 GitHub release 托管与所属仓库完全无关的内容的，我就比较反感了。

@sephinh 德便

FIDO ？

有活跃的五笔输入，windows 自带的就有，应该是和拼音一样的优先级，就是不知道选择五笔的用户多不多

好，支持，威武，有希望了 🐶

大概看了一下 cname 的规范，感觉好霸道啊……
不过大概懂了，是因为要配其他记录，所以一级域名不做 CDN，通过跳转到 www 让用户走 CDN。
结贴。
所以理论上，地址栏手输域名访问的话，直接输入 www 域名更快？要是一级域名太远访问太慢，用 www 即可解决？

之前好像有人拿 GitHub 托管 12306 刷票脚本的，把 GitHub 当 CDN 用，好像差点把 GitHub 跑崩了……

squash 是不经常用的一个功能，一般只在 master 上用。
通常是在 开发分支上进行团队开发，团队中的每个人又在开发分支上迁出多个功能或修复分支进行开发。功能分支和修复分支完成后合并到开发分支。等到开发分支上面的各个功能都稳定之后，合并至主分支发布版本。其中主分支通常为 master，开发分支为 dev，功能分支和修复分支各自起名字。
一般来说，dev 分支处于开发阶段，代码改动量较大，功能变化较大，所以应该尽可能的保证 commit message 尽可能详细，越细越好，这样也更容易发现问题。而代码一旦合并到 master 分支，就表示功能基本稳定了，要发布版本了，版本都发布出去了，精细的历史信息用处就不太大了，所以在 dev 到 master 的时候可以只在 master 上保留关键的信息，其他信息就不用合到 master 了，保持主分支的干爽。
所以 squash 很少用，日常开发基本直接 commit，amend 是在确实应该合并的时候用的。