“为什么不能只用熵编码这一个步骤”
因为只用这一个步骤的话，压缩比太低。
想要提高压缩比，允许有损压缩，就会有那些频率域上的操作和前后运动估算之类的方法。

比如 obs 搞一个虚拟摄像头？

commit 上右键，show repository at revision ，给你一个这个版本的文件树，就能随便看了

可能的原因我觉得一个是软件是否为了预览而优化预读取、缓存、解码等，另一个是是否有硬件 jpg 解码器和软件是否能使用硬件 jpg 解码器

如果要深入底层去做团队或者公司的基础设施，那有可能需要。其他情况下需要的可能性挺低的。

举两个例子，为什么有时候需要加标注，可以多想想为什么不允许修改，为什么只读引用没还回去而影响了修改。

第一个例子是一个很常见的情况，这个就是标注的意义
第二个例子举了一个编译器自动加 'a 会导致无法编译，必须手动加标注的例子

https://gist.github.com/misdake/364f00d6d7c43d88b5a5d2e7ba1144b9

fn index_t_words(sentence: &String) -> HashMap<&str, usize>，其实隐含了输入和输出各自唯一的引用都是'a 。
认为唯一的输出引用的生命周期和唯一的输入引用的生命周期一致，绝大多数情况下是正确的。

fn index_t_words(sentence: &String, bias: &str) -> HashMap<&str, usize>，不能直接确定 sentence 和 bias 的生命周期是一致的，也不知道返回值的生命周期是什么样子：返回值引用了 sentence 还是 bias 还是'static ？，函数返回的时候，sentence 和 bias 能不能释放输入的引用？如果返回的引用还没释放时，bias 被修改了，允不允许？
在代码稍微复杂一点的情况下，假定所有引用的生命周期相同是非常危险的。

过充过放会减少寿命。我感觉过放影响更大，以前我和老婆用同款手机，2 年后换机的时候删掉她手机的 app ，续航仍然是她的两倍。

我的方法：
如果文件能打开，打开然后用打开的软件分享，分享到支持 smb 的文件管理器上，存到电脑硬盘里
如果不能打开，就“保存到手机”，打开支持 smb 的文件管理器，默认是 Download ，点开 weixin 文件夹，长按复制文件，复制到电脑硬盘里

一次性的镜头 /眼镜纸

local history 救过我好几命

有小的电热锅的话，可以买两板鸡蛋，直接蒸或煮，或者蒸鸡蛋羹

大也有副作用，延迟会增大，命中率的提高可能陷入瓶颈导致弥补不了延迟损失，导致性能降低。
L1 都是那么一小点，就是为了保证几个周期内一定能拿到。

开启优化，如果函数内部很容易推断出不可能修改长度的话，是会优化掉的

尽量同频率，混插频率会用较低的那个，买高了费钱。
如果牌子大一点的话，主板和内存厂商的兼容性测试会做得多一些。
可以更新一下主板 bios ，可能包含新的内存兼容性支持。

做好物理报废的准备。我曾经有一个 u 盘用了两年多，突然就写保护了，又过了 4 到 5 年，偶然看一眼又变正常了，接着用 😂

@LeeReamond
服务器端读取图片：比如服务器根据用户头像生成一个海报发个动态，比如给图片加水印，都是很常见的需求
执行脚本：我查了查基本都是图片和文本直接拼在一起，具体的搜一下吧，比如 https://backwallkid.github.io/2017-08/php-vs-python-detect-malicious-img.html