https://mp.weixin.qq.com/s/w8yBgDX3ucKFkW9YbVA-_w
刚好上海 zf 官方公众号发了这个文章

@ruimz 你自己点进去看看，里面大多数是在喷还是在洗呢。你再看看这个帖子，按你的标准，这里有没有给小米洗地的呢？

我回复就是因为很讨厌三楼这种回复，小米 11 取消随机附送充电器的帖子里，你们喷小米，夸小米，喷小米学苹果，夸小米学苹果，甚至喷苹果，夸苹果，我都 OK 。上来 3 层楼不到，去喷别的帖子里面不同意见的用户去了。这就很 low，一边说着意见相反很正常，一边在小米取消充电器的楼里喷那些支持苹果取消充电器的用户。到底谁在双重标准？

如果还有人想喷我，请先不要妄断我的立场，我从来没有支持也没有反对过取消充电器，无论是苹果还是小米。另外，我是苹果小米双持用户，针对这个问题不发表意见，只是讨厌自己双重标准，还喷别人双重标准，上来就把楼给歪了的回复。

@mazk 我个人倒没怎么见到给苹果取消充电头洗地的言论...我见到的都是吐槽的居多，不知道“行”是哪来的。

这个论坛的主流言论在 iV2EX/anti-iV2EX 之间的转换真的是薛定谔到让我跟不上，不过我稍微有点 get 到点了，不管怎么样，喷就对了。

@Chikaku 感谢科普，不过我当时接触到的确实都是 Foxit Reader，后面才慢慢有福昕阅读器，我印象比较深是因为我第一次看到福昕和 Foxit 用了同样的图标时我还以为是山寨的，后来偶尔发现是同一个软件的不同名字，然后还发现是一家国内的公司，当时觉得还挺厉害的，后面接触到过一篇文章讲 Foxit 突破 Adobe 技术限制的，还被圈过一波粉。
结果后来不知道为什么他们阅读器越来越卡，冷启动越来越慢，甚至到最后是最新安装版不如以前不明版本的“绿色版”好用之后，我就慢慢脱粉了。

jQuery 出现所解决的最重要的两个痛点，第一个是好用的跨浏览器的 API （主要是 DOM，其次是 Ajax ），第二个就是傻瓜式的浏览器兼容解决方案。

考虑到 baidu 的用户范围之广，我觉得靠 jQuery 保留对极旧浏览器的兼容还是有必要的。

你的场景跟 extension 是契合的。如果不想以 extension 的模式来用，也有 filesystem API 可以用，Chrome 文档上面有人贴了，我贴个 Firefox 的： https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API，最后有浏览器兼容性列表。

filesystem API 的鲜明例子就是 mega.nz ，不过 mega.nz 对 filesystem API 的应用是因为下载的东西要在本地作解密，他们的宣传点就是上传下载过程中的加密传输：
https://www.reddit.com/r/webdev/comments/2f6yfh/how_does_the_interesting_httpsmegaconz_download/

顺便贴个浏览器 storage 配额限制：
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria
https://chromium.googlesource.com/chromium/src/+/refs/heads/master/storage/browser/quota/quota_settings.cc#77

贴几个 Apps 给你参考：
https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb
https://chrome.google.com/webstore/detail/chromeadb/fhdoijgfljahinnpbolfdimpcfoicmnm
https://chrome.google.com/webstore/detail/vnc%C2%AE-viewer-for-google-ch/iabmpiboiopbgfabjmgeedhcmjenhbla

还有官方文档：
https://developer.chrome.com/docs/extensions/mv2/devguide/
支持的所有操作：
https://developer.chrome.com/docs/extensions/mv2/declare_permissions/

chrome 地址栏输入：
chrome://apps/

(hd0,2)是(hd0,msdos2)的简写

sdc 代表第一个 usb 磁盘之类的，上面写错了

https://askubuntu.com/questions/232215/stuck-in-grub-rescue-mode

输入 ls 查看所有磁盘和分区：(hd0) (hd0,msdos2) (hd0,msdos1)

然后逐个：
ls (hd0,msdos2)/
ls (hd0,msdos1)/
找到那个有 boot 子目录的分区，也就是你的 Ubuntu 分区

假设(hd0,msdos2)是你的 Ubuntu 分区，然后输入以下命令：
set prefix=(hd0,2)/boot/grub
set root=(hd0,2)
insmod normal
normal

然后你就进入 Ubuntu 了，然后在 Ubuntu 里打开 Terminal，输入一下命令，修复损坏的 grub 记录：
sudo update-grub
sudo grub-install /dev/sda

这个答案没有说 /dev/sda 是什么意思，注意 /dev/sda 应该是你的启动磁盘，sda 代表你的第一个硬盘，sdb 代表第二个，sda 代表第一个 usb 磁盘之类的，nvme0n1 代表你的第一个 m2 接口的 ssd 硬盘。你可以自己 ls /dev 目录去找正确的那个安装了 grub 主引导记录的磁盘。

@xzour 他们的意思是类似这种结构
收款记录：HashMap {
xxx: [],
yyy: []...
}
发票记录：HashMap {
xxx: [].
yyy: []...
}
然后遍历 HashMap 两边同 key （用户 id ）的数组进行对对碰。


也可以
HashMap{
xxx: Map{ 收款记录: [], 发票记录: [] ... }
yyy: Map{ 收款记录: [], 发票记录: [] ... } ...
}



上面三种结构效果几乎都是等同的，时间复杂度的数量级上不会有什么差异.

@xzour 如果我是你，就实时核销，他们要反清帐，对应核销记录就置 revoked 。怎么实时核销，想写了就每次创建收款记录 /发票记录时自己算，不想写了让财务人员自己选，自由还给他们，做错了是他们的问题，你的责任是保证系统不出错，逻辑没问题，尽量提示他们的低级疏忽，尽量简化他们的操作，但没有义务承担他们所有操作的责任。

如果要看客户期末余额，就收款 /发票两个表 group by user_id，sum 一下相减。
如果要看发票剩余金额，就发票 /核销两个表 filter by revoked, group by fapiao_id，sum 一下 filter 出值不为 0 的。



如果不想大改系统，就用 whosesmile 的办法。你要做的实际上是创建这样一个结构：
[
{ 用户 id: xxx, 收款记录: []，发票记录: [] },
{ 用户 id: xxx, 收款记录: []，发票记录: [] }....
]
然后遍历整个数组，每个项里面的两个数组采用类似“合并两个有序数组”的方法对对碰。

看了这么多楼都给我整懵了，看了原帖才发现，根本不是这么回事儿。

这个帖子是完美的 X-Y 问题的例子。
建议回答的人先去看看楼主贴出的原帖，在"""""""暴力遍历"""""""（加粗加重）中，数组转字典可以优化计算速度是不存在的。

什么是 X-Y 问题： https://coolshell.cn/articles/10804.html

第一个问题感觉本质上是数据库结构设计有问题，依我对财务极其粗浅的理解，收款和发票理想不该是一对一，最次不该是多对多的关系么。

第二个问题我建议你还是从根本上解决，从后端实现，不知道为什么你觉得改前端代码就不算改代码了...而且前端传表达式这种东西，漏洞，bug 会非常多。我不是很懂计算提成这种东西敢放在前端计算是什么操作。即便只是 bool 条件，也是很容易存在很大漏洞的。更别提如果后面上了权限管理，你可能需要 hack 表达式解析引擎了。我查了一下你说的这个 Flee，298 个 star，上一次提交是二月份合并了两个 pr，再上一次提交已经是去年三月份了，这种不仅用的人少而且 maintainer 不活跃的库真的不建议用在生产环境。

@daijialong
1.Python 是极好的入门语言，没有学过编程的人，最关键的是先培养出来怎么跟计算机“对话”，让它“听你话”的意识。在这一点上，Python 是最友好，社区支持最健全，资料最多的。
2.Python 的生态足够健全，“语法学完”到“解决现实问题”的过度更平滑。我以前是 C/C++入门，学完得学 C 标准库，然后 Windows API/MFC 才真正能写“看得见”的程序。这一套学习曲线太陡峭了。PHP，且不说现在还有多少新项目在用，跑起来到语法到解决现实问题的曲线也太陡峭了。
3.Python 语法足够健全，深入了以后，类，函数式，该有的都有，学会以后转其他的都方便。
4.我对你上面逗号分割的三个半句都持保留意见。真的很少见发个帖子，几乎没一个字是对的。