才发现取消动作，会反直觉记录在 History 的 SQLite 下载表里，且受到 90 天约束

https:// www. nirsoft. net/utils/browserdownloadsview-x64.zip
https:// static. centbrowser. cn/win_stable/5.2.1168.83/centbrowser_5.2.1168.83_x64_portable.exe

如题，开下载前询问每个文件的保存位置的设置，使用浏览器自带下载，例如点击下载百分便携版的链接，弹出下载询问框时（网速太快后台其实已自动静默下载完毕），这时候点击询问框里的取消按钮，并不是跟直觉感受一样不会实际写下载表记录，或在取消的那一刻就删去本次预下载记录。甚至反直觉的事实是在 History 文件里静默残留前端不可见记录，在手动编辑清理或等 90 天后自动清理前后，这些垃圾无用记录导致记录编号键值持续膨胀。所以 History 导致浏览器卡顿（目前我没卡，只是综合参考部分其他人有过这种情况的历史发帖说的），不一定只有其表象原因，也有一部分功劳是最近这些静默残留不可见记录共同推波助澜。今天通过 nir 软件检查了一下 History 文件下载表，才发现这个反直觉记录（之前一直没留意过），似乎取消记录一样受到 90 天影响，超过 90 天的下载取消记录会被自动清除（但编号膨胀不可逆或无法碎片再整理），而不是所有历史取消一直永久累积，因为目前取消行为记录总共一百多条（所有正常下载含各种取消等共一千七多，各种正常增删取等，编号最新去到一万五，现在倒是好奇那些 History 卡浏览器的，记录总共去到了多少，好制定个大概预警上限，老大可在上限快接近时让浏览器发出警告提醒，这也可以发展成百分口碑优势之一，因为其他竞品都没有），最早一条是在今年四月，早于四月的取消记录不存在，但四月之前，印象里确实存在过多次取消动作。避免吵架或误解，先叠个宇宙声明甲，取消动作很正常，我没有为了取消而取消或人为炮制水贴素材，正常的取消原因有很多很多，有时候是误点击，有时候是仅简单下载响应测试，有时候是与期望下载内容不符，有时候是网站头里带有强制下载非用户行为等等，这个帖子只是记录了我本次反直觉的发现和一些思考，无意叨扰

S8F8ry

🤔 理论上数据条目的编号大小并不会导致性能问题，它只是一个会自增的记录 ID 而已。通常是表中所记录数据总量才会对查询性能造成影响。

S8F8ry 发表于 2026-7-9 12:09
🤔 理论上数据条目的编号大小并不会导致性能问题，它只是一个会自增的记录 ID 而已。通常是表中所记录数据 ...

是的，关于这个前端可见加不可见的总记录数或百分比范围，一直没个标准和自动测试数据或真实样本作为支撑。目前观察到大概有这几个方面，总数据量，某个文件记录过大，不可见的冗余或不可见的异常数据，低性能电脑。就像暴雨一样，总得有个大概风险预警水位，在即将或临近风险水位时候，主动提醒用户紧急迅速转移撤离，好过龙卷风突然平地而起没有任何避险措施。说到历史文件压力测试，貌似龙虾会很适合这种重复数据测算工作。得到测试数据后，就可以在设置里增加一个文件压力达到多少百分比提前提醒开关，又或者直接在 chrome://history 前台显示参考用量或者恢复关闭标签按钮右键里，定时缓存成纯文字的总数据量，当右键这个按钮时显示参考用量描述，类似手机无限流量卡，也会面向用户提供数据用量参考。再仔细想了想，这种做成插件灵活性挺高的 🤔 但精确度受限于 v3 用户侧载，没有浏览器自身权限大而详细方便，假如浏览器向可信插件提供 api 本地数据安全接口的话，倒也还好。