# 惊事录：与优秀的人一同成长 Original: Author: [奶爸](https://lifelonglearn.ing/users/3b04650c-8231-499b-8ef0-381fc4d7efb0) Published: 2025-03-19T16:21:20Z Updated: 2026-09-27T06:57:43Z Version: 1 职场 9 年，自己也有些固步自封了，多少思维有点固化，这是人性使然。如果一个人能长期拿捏工作且思维没有一点僵化与偏见，真的很佩服。排斥没见过的东西，真的很可怕。希望我尽量保持空杯心态不断进步。 所有 case 按照时间顺序倒序排列，Think Growth。 ## 100 不断进步 其他就是些小的技巧啦，比如说在写 SQL 时，注意幂等 `update t set a = 1 where a != 1` 这种的小细节。或者啥巧妙的 design pattern 的运用。 ## 5 逆向思维 经常锻炼自己的逆向思维形成肌肉记忆，在做Solana合约时遇到PDA账户大小的问题，包括怎么一步步的创建一个10mb大小的PDA账户。在这个过程中我只是一步步解决了怎么逐步创建大账户的问题，遇到和解决了很多的限制。唯独没有逆向思考一下能否将一个大账户改为小账户，会发生什么。结果被审计查出来高危 bug。 因为在向前的过程中耗费了太多力气，忘记了如何向后。 ## 4 追寻本质 在做Solana合约时，有个 cpi invoke accounts 数量限制，我已经黔驴技穷了，试过了所有想到的方法，已经放弃思考了。结果优秀的同事找了 cpi 调用相关的测试用例，拉下来 solana 源码，通过跑测试搞清楚了这个限制的作用范围。他给我一说我立马发现了问题，马上解决了这个技术上的卡点。 这个同事大大震惊了我，我在反思我为何会这样，我为啥没有想到去看测试用例，如果再了解具体的功能或者功能的上下限时可以看相关功能的测试代码。 ### 4.1 基础知识 关于 Solana 内存优化，Solana 执行时很容易超出内存限制，vec(rust)，slice(go) 在扩容时都有翻倍的策略，这点我就没注意到，还是被同事 点出来的…… ## 3 信息获取 就信息获取这方面有两次被震惊 ### 3.1 官方文档 还是 Solana 需求，最近 Solana 需求做的多。有个需求需要验证链下签名，使用 Ed25519 或者 ECDSA 来做。然后我就开始 Google 「solana ed25519 verify」看了一些几个问答和一个 GitHub 的demo。结果同事直接找到了官方的 Native Program Ed25519Program，震惊到了，比我找到有效信息的速度快多了。 后面我在复盘过程中感觉以后了解什么东西第一步先到官网，我通过 Solana 网站的 「Ask AI」中输入「ed25519 verify」第一篇就是同事发的文档链接。 ### 3.2 单纯震惊 我们准备在 Solana 合约中使用 ECDSA 验签，我还没开始研究。同事直接甩给我了解决方案 [https://docs.rs/solana-secp256k1-recover](https://lifelonglearn.ing/r/go?url=aHR0cHM6Ly9kb2NzLnJzL3NvbGFuYS1zZWNwMjU2azEtcmVjb3Zlcg==) 我简单看了下回了句「OK，就是不知道这个库有没有经过审计」，结果同事说这好像是官方的，我点进去看了下repo确认是官方的。 单纯震惊于他并不没在Solana上花太多时间，却对这个不常见的技术点上手的如此快，很快找到了可靠的解决方案。 ## 2 一知半解 有些文档真的是写的差劲，或者找起来费劲。比如说 Solana AddressLookupTable 相关的内容，我现在已经对 AddressLookupTable 十分了解了，但是在最开始开发 Solana 时，我对 AddressLookupTable 真是完全摸不着头脑，我也没有去操作去试，一味的翻来覆去的看文档，结果还是一知半解。 直到我自己创建了 AddressLookupTable、解析了 AddressLookupTable 的 data 和完全了解了 Version0 Transaction 结构之后我才完全了解这个东西。 有些同事是真的 ​**有点东西的**​，我自己很多入门的知识也是从同事的代码、博客中学来的，他们的博文写的是真的好，直观又完整。 了解一些技术的原理一是看自己熟悉的语言的实现，二是要完全理解它，比如说了解交易结构，把交易打成hex字符串逐字节解析它的内容。 ## 1 相信本质，谁也不轻信 接手了点 SpringBoot 的一点后端业务的一个小的接口，设计一个DB表创建记录，记录用户条款已读状态。因为我之前一直做 Go、PHP 没有 Spring 框架的 ORM 的使用经验，不知道它背后会做到什么程度。还跟同事确认了过一些锁、唯一索引问题。结果出现了一个用户一个条款存在多条记录的问题，最后我背的锅。我其实从原理上就感觉这个同事说的有问题，这么做可能会出问题，但是当时由于相信他没有坚持去确认…… 结果后面出了这个问题被吊起来打。 ## 0 再合上游我是狗 这是我加入团队不久第一次被坑，刚加入团队在做一些前端的事情，前端mono repo的master分支经常force push，导致我的分支在不断rebase，写三天代码rebase两天，经过两次这种事之后我只通过无冲突pull request merge后拉master 代码，尽量避免开发过程中拉master新代码。