web-component+shadow dom 是最好的选择，里面可以确保你的 css 不和用户自己的 css 冲突
设置内部的 html 可以直接在 shadow-dom 里设置 innerHTML
（除了直接插入<style>到 shadow-dom 以外，也可以用 adoptedStyleSheets 的 api 去设置 shadow dom 内的样式）

libgcc_s 是 gcc 自己生成的依赖，没有的话，大概率只是静态链接上了，比如-static-libgcc 一类的选项，或者手动指定 spec --with-specs=%{!shared-libgcc:-static-libgcc}来避免链接到动态版本的

谷歌日常 a/b/c/d/e/f 测试（）
理论上可以在 chrome://flags 里看到选项，default 的话，大概就是随机

推荐用 UUIDv6 ，有序而且随机，128bit ，基本撞不到

@gps949 问题就是中间人攻击在 http 的场景下，不需要在客户端上搞事情啊，只要中途魔改你的代码即可，你没有任何办法验证，因为验证的代码也可以被改，不是说你实现有问题导致出事，而是就算实现完全没问题，假设一点协议上的漏洞都没有，它也不能提供任何可靠的安全保障
https 的一个性质就是双方有一个预先共享的信息（和代码），而这个信息和代码显然不能通过同一个不安全的信道传输
一个最简单的攻击方案，中间人直接在它设备上模拟浏览器，将渲染结果传递给受害者，然后把受害者的输入通过这个模拟浏览器传回服务器，而这个过程中，受害者除了真的去阅读每一行代码以外（实际上不可能），没有任何感知
https 的情况，你中间人要做这个，在没有服务器的证书的情况下，就没办法伪造你服务器的身份，因为验证代码和证书链都是已经预制在客户端上的，你不能在不接触客户端的前提下去修改验证代码或者注入证书，因而客户端总是会显示证书错误信息

@gps949 你不能安全实现，攻击者预计可以直接修改你的代码，剥离或者直接魔改加密代码，而且 TLS 的核心在于证书链，要有方法证明证书符合需求，因为你的代码和证书终究也还是通过 http 传输的
（当然你可以说你能给代码加 114514 层混淆，但这么比就没意思了）

确实有办法对一些录制屏幕的 api 排除一些窗口，但是那会直接变黑，因为 windows 决定被盖住的部分就不画了，根本就没有想过数据
或者采用单窗口的录制方式，那个可以录制被盖住的内容，但是显然不能完成全屏录制的需求

@ChatGPTPRO 你不会真按那个答案里的 html-to-canvas 去录制 canvas 了吧。。。这不是绕了一圈吗，肯定浪费了

@ChatGPTPRO 你可以从里面挖出原始 canvas 的啊，再不行直接 document.getElementsByTagName('canvas')

canvas 可以用 captureStream 生成流
https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/captureStream
然后用 MediaRecorder
https://developer.mozilla.org/en-US/docs/Web/API/MediaRecorder
不过这个只能生成 webm ，可以考虑使用 ffmpeg wasm 来转换成所需的 mp4 格式
相关代码网上一大堆，这里就不列了

你登录微乱账号就会云端同步了

51%是什么概念你能理解吗，100%不能篡改，意思是所有基础设施控制者都不能在创建后修改或者伪造的东西，那恐怕只能把消息摘要通过一些技术手段广播到全宇宙了，然后需要验证的时候从反射回来的信号提取（）

冷知识：你可以买 4G/5G 调制解调器的

有没有一种可能，问题在于成本，单独开个模，几个 w 就进去了，选项越多，销量越少，成本越高

一般是你自己内存写泄漏了

每次开进程损耗更大吧（）

一般来说，不会用 linux 权限来管理 web 的权限...
web 服务器的权限都是最小化的，甚至是 nobody

不能 chatgpt 不代表国内的大模型就不能用了（
且不说你可以本地 LLaMA 微调一个，国内也不是没别的厂提供了