这篇总结感觉写的很好 https://www.v2ex.com/t/675945

当然所有的递归都能转换成迭代(完全模拟，此时时间复杂度和空间复杂度都一样)
将递归转化成迭代非常难
这里有一个 2013 年写的系列 https://blog.moertel.com/tags/recursion-to-iteration%20series.html (我正在翻译)

完全可以自己写，先得到哪些文件大小一样，将大小一样的文件计算 hash 第一步就排除大多数文件了

粉丝少也可能是你没有输出干货, 或者没有吸引观众的点
https://space.bilibili.com/388576777
https://space.bilibili.com/483162496

这些 up 主关注有这么多是真的有很吸引人的地方
另外，关注少不要紧，只要是真粉，还是有机会变现的

@Quarter

做这个的太多了,竞争激烈.....PDF 和 office 互转估计是用的 solidframework
另外我用过的绝大多数在线转换器都不需要登陆使用
也不会说 3M 限制....

如果有朋友是律师就找他们，他们专业。如果没有....好像只有仲裁，因为自己找律师能不能要回钱，都需要出律师费

处理过类似的项目，用 dxf，dxf 规范比较简单。然后写代码在 dxf 和另外一种矢量格式互转就可以了

@bash99 我觉得日志更好的思路是结构化日志(从生成日志的时候就做好规划), 尽量让日志变得更容易查询，而不是直接退化到小范围的 grep

https://docs.timber.io/guides/structured-logging-best-practices


Grafana 是做监控页面起家的，监控系统得到的各种数据本身是结构化的，也很适合时序数据库
用时序数据库的套路去设计日志查询系统不看好

Geohash google s2 Uber H3

瓶颈是磁盘 IO, 针对选一个 hash https://github.com/rust-lang/hashbrown,按行读取,如果 hash 值已存在则跳过,猜测十秒能完成吧

@joesonw 时序数据库当不了 kv, 容纳不了高纬数据，每个需要过滤的信息都放到 meta 里面是不可能的。https://prometheus.io/docs/practices/naming/#labels

大多数查询只关注一定时间范围和一些简单的参数（如：host 、service 等）
以上假设是完全错误的,作为一个查询平台，直接限制查询能力，然后宣称各种好处站不住脚
比如日志里面记录了订单号, 需要使用订单号查询全部相关日志

深圳几乎所有图书馆需要提前排队，开馆十分钟座位都没了，然后市场出现了一堆付费自习室。图书馆很大的作用是给人自习的，藏书可能算附加功能

@hooopo 当然不能