保存时间：2026/4/8 08:36:02
document.body.style.overflow = 'hidden';
about:config → 接受风险 → 搜索并修改以下项：content.notify.interval → 改为 1000000（1秒，默认120ms，减少频繁重排）nglayout.initialpaint.delay → 改为 0（立即渲染，不等待）dom.max_script_run_time → 改为 30（JS超时30秒，默认10，避免超长对话JS被中断）javascript.options.mem.gc_allocation_threshold_mb → 改为 2048（GC阈值2G，减少频繁GC）browser.cache.memory.capacity → 改为 -1（不限制内存缓存，用足64G）browser.cache.disk.enable → 改为 false（禁用磁盘缓存，全程内存，避免IO卡顿）browser.sessionstore.max_tabs_undo → 改为 0（关闭标签页撤销，省内存）dom.ipc.processCount.webIsolated → 改为 8（和内容进程一致）gfx.webrender.all → 改为 true（强制WebRender渲染，比旧引擎快很多）gfx.webrender.enabled → 改为 truelayers.acceleration.force-enabled → 改为 true（强制GPU图层加速）browser.tabs.animate → false（关闭标签动画）browser.download.animateNotifications → falseui.prefersReducedMotion → 1（全局减少动画）network.prefetch-next → false（关闭预加载，减少后台请求）# 找到Firefox PID
pidof firefox
# 设为高优先级（-10，范围-20~19）
sudo renice -n -10 -p <你的Firefox PID>
# 卸载Snap版
sudo snap remove firefox
# 安装官方deb版
sudo add-apt-repository ppa:mozillateam/ppa
sudo apt update
sudo apt install firefox
一个页面崩溃，从健壮性角度应该隔离，安全角度也隔离，是不是？
https://www.doubao.com/chat/{会话ID}，服务器返回一个基础HTML框架，包含最新的几十条对话。GET /api/chat/history?session_id=xxx&before_ts=1600000000000&limit=20
session_id：你的对话ID，用来定位是哪一段历史。before_ts：时间戳，告诉服务器“我要加载这个时间之前的历史”。limit：每次加载的条数，比如20条。before_ts）都不一样，服务器返回的内容也不一样。浏览器会认为这是一个新的请求，不会用缓存。before_ts 是标准还是自定义？beforecursoroffsetlast_idpage_tokenbefore_ts 的时间戳从哪来？怎么同步？created_at）。created_at 记下来，作为下一次请求的 before_ts。before_ts。SELECT * FROM messages WHERE created_at < ? ORDER BY created_at DESC LIMIT 20。created_at 作为新的 before_ts。page=1、page=2 来请求。before_ts 就是一种游标）before_ts），动态查询“游标之前的N条数据”。before_ts 发起 API 请求。before_ts 请求，不用你手动一直往上滚。需要吗？before_ts 真的需要保存游标吗？before_ts）带在请求里。GET /history?limit=201700000000。GET /history?before_ts=1700000000&limit=20SELECT * FROM messages WHERE created_at < 1700000000 ORDER BY created_at DESC LIMIT 201699999900。GET /history?before_ts=1699999900&limit=20before_ts。1600000000，手机上还是从最新的开始，两者互不影响。before_ts，不认“哪个设备”，所以天然支持多端独立。before_ts 发过去就行。WHERE created_at < 目标时间戳 的查询。<html> 标签 → 开始构建 DOM 树。<body> 标签 → 开始渲染页面。<div class="message"> → 把这个消息节点插入 DOM 树，并立即渲染到屏幕上。<img src="..."> → 先占个位置，图片异步下载，下载完再替换上去。<body> 标签是一开始就给你的。<body> 里面的。width/height 属性或者 CSS 占个位置，图片下载完再调整。max-width、margin、padding），浏览器根据这些规则自动计算位置。<div class="message">...</div>）。before_ts 是客户端带过去的游标，服务器无状态，不需要保存任何用户的加载位置，天然支持多设备。before_ts 到底是什么next_cursor: "MQ=="，这个字符串是 Base64 编码后的内部偏移量，客户端只负责原样传回去，不需要理解它是什么。offset 或 created_at，再去数据库查询。before_ts 或 cursor）。Range 请求）确实需要服务器维护偏移量，但那是针对静态文件的。SELECT ... WHERE id < ? LIMIT 20，服务器只需要返回这 20 条数据，不需要知道整个历史有多长。before_ts 是一个不透明的游标，服务器无状态，所有状态都在客户端，这是现代高并发服务的基石。SELECT *
FROM messages
WHERE session_id = '当前对话ID'
AND created_at < '你传过来的 before_ts'
ORDER BY created_at DESC
LIMIT 20
WHERE created_at < X{ created_at: { $lt: X } }给我一个起点，给我多少条，我给你对应数据。
session_id + before_ts + limit=20LIMIT 20 这个逻辑 依然 100% 存在，只是名字不一样。SELECT * FROM message WHERE session_id=? LIMIT 20
db.messages.find({ session_id: ... }).limit(20)
整个对话存在一个大文件里，像 txt 一样，从头读到尾？
给我某会话，某时间点之前的 N 条
一条消息 = 一条结构化小记录
{
id: 唯一ID
session_id: 对话ID
content: "你好"
created_at: 时间戳
role: "user" / "assistant"
}
LIMIT 20https://www.doubao.com/chat/会话IDGET /api/chat/history?session_id=xxx&before_ts=1700000000&limit=20
<html>
<body>
<div id="chat-container">
<!-- 消息一条一条插在这里 -->
</div>
</body>
</html>
<body> + 一大段 JSbefore_ts=最新.message、.content 这类你在浏览器里能看到的 class服务器直接拼好一段 HTML 发给我浏览器直接渲染不就省掉 JSON 解析那一层吗？
{
"role": "user",
"content": "你好",
"time": "2026-02-25"
}
DOM 也是树结构，为啥不直接传 DOM 结构？
直接返 HTML 确实少一层解析，更快。
<message>
<role>user</role>
<content>你好</content>
</message>
{"role":"user","content":"你好"}
{}[]struct* this。this->vtable->func()，就实现多态。// 虚表结构体（对应 C++ vtable）
typedef struct VTable {
void (*sayHello)(void*);
} VTable;
// 类 = struct + vtable
typedef struct Base {
VTable* vtbl; // 虚表指针 ← 这就是 C++ 偷偷加的那个
int data;
} Base;
base->vtbl->sayHello(base);
_Init()_Release()AEEINTERFACEDEFINE_VTBLPREFIX_NAMECLASS MyClass {
void MyMethod();
};
struct MyClassVtbl {
void (*MyMethod)(MyClass *);
};
struct MyClass {
struct MyClassVtbl *vtbl;
};
如果宏能解决 parser 的问题，那就不需要 parser 了。
编译出错，那是祖坟冒青烟；编译不出错，运行时炸，那才叫折磨。
C++11 之后已经吃力，C++17 不专门学根本看不懂，C++23 简直是外星语言。
// 从一个非对齐地址读 int
char* p = buffer + 1;
int value = *(int*)p;
只有在真实 Target Machine 上才会出现。
#define MAX_CONTACTS 800 // 写死在代码里
Contact contacts[MAX_CONTACTS];
send() 实际返回 -1 / EAGAIN / EWOULDBLOCK单条 HTTP 请求体长度有硬限制！超过 几 KB～十几 KB，网关直接截断、直接丢包、不报错、不通知。
一个 HTTPS 会话，最多存活 X 秒（比如 180 秒 / 300 秒 / 你说的 800 秒左右）。时间一到，不管你在干嘛，直接切断连接。
“它为了保证最大服务量，不让被 abuse，到时间就会断掉。 你一个 HTTP session 是有限时间的。”
我们的 HTTPS 网关会话超时是多少？答案：默认 300 秒（5分钟），到点强制断开，不通知、不解释。
把电脑的数据包，原封不动转发到移动网关。
char buf[1024]，毫无压力优化一开，指令重排，代码对不上源码，调试器指的位置全是假的。
#ifdef DEBUG 里少写了一行初始化编译器 10% 是语法解析、代码生成，90% 的工作量全是优化。
优化之后出的错，你想到死也想不出来。
gdbserver :1234 ./your_service
target remote 服务器IP:1234
stop 单步调试？→ 整个服务卡住→ 连接超时→ 链路雪崩→ 直接线上故障