@invadv 在下载镜像、备份文件，说不好过几个小时就哭着来论坛里求助了。。。 😂

@Oliveria 是这个项目老哥： https://github.com/JSREI/ast-hook-for-js-RE ，有兴趣可以一起维护哈 😀

@unregister #44 啊老哥如果是内部框架的话谨慎着点，对于内部框架的快速上手可以多问问周围的同事领导，模仿着他们的方式去使用比较稳，而且这种内部自研框架一般坑会非常多，这种内部框架一般都是 fork 开源的框架进行二次开发甚至就是完全模仿，底层是照抄的，上层的 API 啥的改一改就变成自研的了，你花费在内部框架上面的时间学到的技能很可能不具有通用性，可以把精力着重放在学习内部框架的底层原理上，或者更多的是结合内部框架来理解它模仿的那个框架（比如某些公司基于 gprc 封装自己的 rpc 框架搞出来一堆上层的规范和协议啥的，这个时候就可以下钻把精力更多的放到更底层的 gprc 上而不是纠结于最上层的 API 啥的怎么调，底层原理这个技能是通用的，你离开了这家公司也有用，并且对你以后发展也有用），总结下来就是尽量去卷能够在你整个职业生涯中都能发挥作用的技能，加油祝好！ 😋

@somebody1 心理活动估计跟 #10 楼所说差不多，或者更严重一点的：

- 心里已经觉得你技术不太行或者出活不太行（大概率是出活，毕竟这个会影响到他 KPI ，如果只是技术不太行不影响到他利益的话他可能不会多嘴），但是又还没差到要干掉你的程度或者他因为个人情感啥的不太想干掉你（毕竟没有谁心理变态整天要开人，人都是有感情的，马仔能凑活着用就凑活着用），但是他能看到事情已经是在向很不好的那个方向发展了

- 考虑到你的自尊心他不能说得太直白，就随便聊聊估计

- 如果持续一段时间他觉得还没啥改善，估计就会着手开始换人了。。。

op 可以主动找 Leader 聊一聊，看看有没有更具体的建议啥的，如果只是某项技能上的缺失（比如某个技术框架、或者某些软素质的方法论啥的），你卷一卷学会了受益最大的是你自己，但是如果是要靠延长工作时间才能改善的，就只能六字真言，要么忍要么滚。。。 😂

七年过去了，op 怎么样了，得到当初想要的东西了吗

@nuk 是的老哥，所以压缩分为了两部分：

1. 一部分是栈内部的压缩，这一步相当于是所有的栈共享了一个全局字典来压缩自己内部的重复部分

2. 一部分是栈之间的压缩，完全相同的栈就直接引用同一个 id ，有点类似于 jvm 里的 fast throw 机制，完全相同的栈从第二次开始就是引用的之前的 id 而不重复存储，相当于把整个栈压缩为一个整数

对了怪我的背景故事介绍不完整，他那个工具调用栈不只是异常抛出，他那个工具是通过 java agent 技术给代码添加 hook 点来检出漏洞（原理跟 arthas 类似），每个 hook 点都会有对应的调用栈，hook 点是用户可配置的不可控，甚至可能会出现用户把每行代码都 hook 的情况。。。

@1423 #6 哈哈哈我有点慌呗，我在压缩这块还没太多经验属于刚入门还在各种探索寻找案例练手，我怕自己有想不到的点导致后面全都是错的心态就真崩了那，发到论坛里让大家喷一喷聊一聊能更完善一些有问题我也能及时调整，我之前出现过埋头造轮子造完才发现因为最开始一个很基础的东西没想对到后面全都是错的整个都白费劲哈哈哈。。。😂

@1423 预训练字典的方式也跟那个工具的作者讨论过他否定了，他的业务场景不太满足，数据拿不到那是个类似私有部署的 CLI 工具，要训练只能在用户自己的电脑上训练。。。🤣

@1423 通用的压缩算法大部分都是基于字典和偏移尽量消除重复数据，比较依赖的是压缩的时候的字典窗口大小和一次性被压缩的数据量的大小，调用栈是热数据需要能够随时查询不适合批量压缩，如果 gzip 只能针对单条调用栈进行压缩，那个工具的开发者现在已经是在这么做了，消耗的资源（ gzip 的内存、CPU 消耗等）与效果做性价比的话不是很理想（但也能凑活用。。。），所以才想着看看探索更极致的优化，当然这也只是一次尝试，也很可能还不如通用的压缩算法也说不好 😅

@kneo 代码在写了老哥，方案设计写了大概一个小时，只是感觉算法应该还有挺大优化空间，论坛里牛逼大佬比较多先发出来让大家喷一下，这样我在写的时候也能及时调整，代码估计要写个两三天国庆后应该能发出来具体效果 https://github.com/stack-database 😀

@wqq096737ink 橡胶耳塞跟硅胶耳塞是一回事吗老哥，我去搜了一下，我之前戴的好像是海绵耳塞，硅胶好像说是确实不太一样，搜到一个戴思的硅胶耳塞准备下单了 😀

@wqq096737ink 我大学的时候试过戴 3m 耳塞睡觉，长期带的话耳朵容易有炎症，不过可以作为 plan b 偶尔用一下... 感谢老哥建议 😁

@GeruzoniAnsasu 感谢老哥，我去京东搜搜看看 😀

@xing7673 老婆规定她睡觉的时候我需要也在卧室陪着她要不然她一个人害怕，她把这个定义为爱情，意思就是不听的话就要挨打。。。 😐

[如果使用 redlock 的话，需要多主部署，为了一个分布式锁更改 redis 部署模式或者多部署一个 redis 集群， 多少有点得不偿失的感觉。]

是的，我之前也想过这个问题，在降本增效的大环境之下，某些不是特别重要的业务又有分布式锁的需求，到底值不值得引入一个组件来解决？投入产出到底划不划算？还是就干脆随便糊弄糊弄正确性就不管了，就看命玩俄罗斯度盘？

并发又不高又要保证正确又不想有资源浪费，后来我就想妈的干脆把数据库做成分布式锁，于是就有了这个开源项目：
https://github.com/storage-lock

项目还在开发中，常用的数据库基本都支持了，后续将逐步支持在任何能存东西的地方都能当做是一把分布式锁，目前还差文档啥的没补全，欢迎大家 flow/star 跟踪项目进度，提出意见啥的。。。😀

@0o0O0o0O0o #6 感谢大佬推荐，看起来 star 数不少应该挺多人在用，收藏了，打算先用 #1 推荐的 vercel 试试，等 vercel 免费额度不够用了就换这个啊哈哈哈。。。 😁

@inzufu 感谢大佬回复，之前用过 notion 多人协作写文档，体验确实很好，还有 AI 啥的，但是因为项目是放在 GitHub 上的，所以寻思着最好还是托管在 GitHub 上😀

@rimworld #9 感谢大佬如此项目的解答，我也体验了感觉很不错，打算先上车这个服务商了，免费额度不够用了再说，唉，为爱发电的开源项目没有太多预算投入。。。😀

@rimworld 看起来是个 sass 服务商啊，感谢老哥我寻摸寻摸去。。。