@nthhdy

文本有无损的硬性需求，即使压缩率低也没办法。
图片和视频没有无损的硬性需求，相反，尤其是视频因为原始内容太大太大，超高压缩率是很多情况下的硬性要求。

另外你说的运动预测你说的是对的，不管有损无损，都可以提高压缩比。（不过这个就不是熵编码的范畴啦）
不少提到的方法最后都要经过一次熵编码，但感觉就像是最后的万金油方法或者兜底方法，而不是真正压缩数据的地方。

另外开阔眼界的话，png 里面用到的压缩方法也挺有意思，还有最近的 qoi 压缩，都是很针对图片的压缩方法。可能比熵编码更好一点
How PNG Works: Compromising Speed for Quality: https://www.youtube.com/watch?v=EFUYNoFRHQI

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

比如 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 ，可能包含新的内存兼容性支持。