一些其他

金额：6 个月的生活开销，年化收益：1.5% - 4.5%

这个篮子里面放的是你的经济保障使用的钱，要存取灵活，不能承担任何风险。他将在你遇到问题的时候为你提供 6 个月的缓冲期。

Growth Basket

金额：与 High Growth Basket 是均分的，年化收益：11% - 13%

这个篮子里面储存的是你用来购买 ETF 的相对稳定且能获得较好收益的资金。

High Growth Basket

金额：与 Growth Basket 是均分的，年化收益：15% - 25%

这个篮子是投资你比较看好的，股票、期货等高风险高收益产品。

Luxury Basket

金额：依据 Growth Basket & High Growth Basket 的收益来定，年化收益：0%

这个篮子里面的钱来源于 Growth Basket & High Growth Basket 的收益，为了享受生活使用的。可以带家人去旅游、购买豪车豪宅。

理财计划

1. 首先先从每月的收入中拿出一部分，直接放入 Security Basket 中，直到你的 Security Basket 满足了你未来 6 个月的开销，然后暂停投入。
2. 第二阶段你可以将每月收入中的部分分成两份，放到 Growth Basket & High Growth Basket 中，每当积累到一定量就到交易平台买入基金/股票。
3. 在 Growth Basket / High Growth Basket 比例不再是 1:1 时，每隔 90 天酌情平衡比例。将高风险资产赚得的收益放入低风险组合落袋为安。
4. 在需要的时候将 Growth Basket & High Growth Basket 的收益提取到 Luxury Basket 中供以享受生活。

每月拿出的部分的比例，不论哪个阶段，只能多不能少，一定要坚持。锦堂同学就有过从 20% -> 0 的经历。

在你不了解金融市场，尚未做好准备时，不要轻易进入。普通人（奶爸）可以将 High Growth Basket 从自己的理财计划中剔除了。

职场 9 年，自己也有些固步自封了，多少思维有点固化，这是人性使然。如果一个人能长期拿捏工作且思维没有一点僵化与偏见，真的很佩服。排斥没见过的东西，真的很可怕。希望我尽量保持空杯心态不断进步。

所有 case 按照时间顺序倒序排列，Think Growth。

其他就是些小的技巧啦，比如说在写 SQL 时，注意幂等 update t set a = 1 where a != 1 这种的小细节。或者啥巧妙的 design pattern 的运用。

经常锻炼自己的逆向思维形成肌肉记忆，在做 Solana 合约时遇到 PDA 账户大小的问题，包括怎么一步步的创建一个 10mb 大小的 PDA 账户。在这个过程中我只是一步步解决了怎么逐步创建大账户的问题，遇到和解决了很多的限制。唯独没有逆向思考一下能否将一个大账户改为小账户，会发生什么。结果被审计查出来高危 bug。

因为在向前的过程中耗费了太多力气，忘记了如何向后。

在做 Solana 合约时，有个 cpi invoke accounts 数量限制，我已经黔驴技穷了，试过了所有想到的方法，已经放弃思考了。结果优秀的同事找了 cpi 调用相关的测试用例，拉下来 solana 源码，通过跑测试搞清楚了这个限制的作用范围。他给我一说我立马发现了问题，马上解决了这个技术上的卡点。

这个同事大大震惊了我，我在反思我为何会这样，我为啥没有想到去看测试用例，如果再了解具体的功能或者功能的上下限时可以看相关功能的测试代码。

关于 Solana 内存优化，Solana 执行时很容易超出内存限制，vec(rust)，slice(go) 在扩容时都有翻倍的策略，这点我就没注意到，还是被同事 点出来的……

就信息获取这方面有两次被震惊

还是 Solana 需求，最近 Solana 需求做的多。有个需求需要验证链下签名，使用 Ed25519 或者 ECDSA 来做。然后我就开始 Google 「solana ed25519 verify」看了一些几个问答和一个 GitHub 的 demo。结果同事直接找到了官方的 Native Program Ed25519Program，震惊到了，比我找到有效信息的速度快多了。

后面我在复盘过程中感觉以后了解什么东西第一步先到官网，我通过 Solana 网站的 「Ask AI」中输入「ed25519 verify」第一篇就是同事发的文档链接。

有些文档真的是写的差劲，或者找起来费劲。比如说 Solana AddressLookupTable 相关的内容，我现在已经对 AddressLookupTable 十分了解了，但是在最开始开发 Solana 时，我对 AddressLookupTable 真是完全摸不着头脑，我也没有去操作去试，一味的翻来覆去的看文档，结果还是一知半解。

直到我自己创建了 AddressLookupTable、解析了 AddressLookupTable 的 data 和完全了解了 Version0 Transaction 结构之后我才完全了解这个东西。

有些同事是真的 有点东西的，我自己很多入门的知识也是从同事的代码、博客中学来的，他们的博文写的是真的好，直观又完整。

了解一些技术的原理一是看自己熟悉的语言的实现，二是要完全理解它，比如说了解交易结构，把交易打成 hex 字符串逐字节解析它的内容。

接手了点 SpringBoot 的一点后端业务的一个小的接口，设计一个 DB 表创建记录，记录用户条款已读状态。因为我之前一直做 Go、PHP 没有 Spring 框架的 ORM 的使用经验，不知道它背后会做到什么程度。还跟同事确认了过一些锁、唯一索引问题。结果出现了一个用户一个条款存在多条记录的问题，最后我背的锅。我其实从原理上就感觉这个同事说的有问题，这么做可能会出问题，但是当时由于相信他没有坚持去确认……

结果后面出了这个问题被吊起来打。

这是我加入团队不久第一次被坑，刚加入团队在做一些前端的事情，前端 mono repo 的 master 分支经常 force push，导致我的分支在不断 rebase，写三天代码 rebase 两天，经过两次这种事之后我只通过无冲突 pull request merge 后拉 master 代码，尽量避免开发过程中拉 master 新代码。