净化Github搜索页，屏蔽cirosantilli等400+人的敏感仓库。
String.includes 确实是包含关系，但是使用 === 的话又太牵强。
你有什么建议吗？
String.includes确实是包含关系，但是使用===的话又太牵强。你有什么建议吗？
回：
通过截取仓库全称字符串的方式，获取仓库所有者，比如cirosantilli/linux-kernel-module-cheat，以/为分界符，获得仓库所有者cirosantilli
然后精确匹配，在黑名单内就屏蔽掉，这样如何？
这样可以做到0误屏蔽，同时可能有一些原先被屏蔽的仓库被放出来，但是我暂时感觉还是cirosantilli等几人仓库的污染程度大一点，其他的可能是毛毛雨，后续通过不断增加黑名单也可以做到很好的效果。
可以做个选项，选择匹配的模式，让用户自由选择。
btw，通过这几天的使用，我发现现有的代码不能做到完全屏蔽黑名单用户，还是能看到一些cirosantilli的仓库，比如在搜索读书 签到，排序方式选择Most Stars时。
我认为主要是pageChange()使用setTimeout来确保时机的问题，这样有点生硬。
有没有什么JS库能实时检测ReactDOM的更新，这是个大问题。
我认为主要是
pageChange()使用setTimeout来确保时机的问题，这样有点生硬。有没有什么JS库能实时检测ReactDOM的更新，这是个大问题。
回：
今天又试了下，似乎搜索读书 签到时脚本屏蔽又正常了，可能今天我的魔法延迟比较低？
但还是稍微分析一下这个问题吧，我并不会js，所以技术上的细节无法帮助你😱，但是我可以抛砖引玉一下。
说不定我会去学下js，因为我真的很想要精确匹配用户这个功能😣
MutationObserver 似乎是一个好的方案。
不过我只是一个高中学子，没有太多时间学习JavaScript，但感谢你的建议 (^O^)。
MutationObserver似乎是一个好的方案。不过我只是一个高中学子，没有太多时间学习JavaScript，但感谢你的建议 (^O^)。
我有一些其他的进展，看私信😉
1. 感谢作者，顺便补充几位:
jk-ice-cream
candice531033938
sky8964
pxvr-official
zpc1314521
jjzhang166
codin-stuffs
cheezcharmer
panbinibn
2. 小疑问:
随着屏蔽词的更新，是否会有少量正常项目被屏蔽？（实际搜索时，我发现似乎其他用户包含屏蔽词的库也会被屏蔽，感觉有利有弊）