如何突破垂直经验限制等多重困境转型 Golang 开发？

本人 8 年后端开发经验，熟悉 Golang 、.NET 和 PHP ，最近逛了一圈 Boss 直聘发现至少 85%的岗位要求垂直经验。

由于之前在公司做的项目多为单体应用和“分布式单体”，可观测性和规范几乎为零，所以自己造一个微服务架构的个人项目来深度实践补足短板，包含工程化管理、CI/CD 、决策记录、更新日志等，可观测性、链路追踪、重试、限流、API 网关、集群资源规划、分布式事务等等应有尽有，5 台服务器塞了一大堆组件，资源极端受限，还有压测报告和负载测试报告，迭代到 6.3.2 ，用 Github Project 管理迭代，经过多个版本的优化，P95 延迟从 1150ms 减少到 34ms ，最大延迟从 22700ms 降低到 213ms ，全部按生产级的要求来做，目前是事件驱动架构，有一些自创的组件。

我知道个人项目很难被认可所以加了压测和负载测试等来证明不是玩具项目。

过往工作经历

过去在公司工作的时候接触的项目架构非常乱，我是知道怎么改更好但阻力很大做不了，甚至 Gitflow 都很难推动，可观测性差，日志要到服务器捞，相对好一点的是放到 ES ，链路追踪和集中化日志管理等完全没有机会实践，CI/CD 更不用说了，大部分是 Shell 。学习大量技能和架构设计却一直没有实战机会，比如领域驱动、事件驱动、微服务等内容早已掌握，然而架构集中在领导手里，所以架构层面的工作顶多是微调和优化，实际上更高阶的技能已经掌握。

第二是多次陷入“高聘低录”的困局，无论经验技能多么丰富，入职后一律被压到最低职级没什么话语权，想要中高级只能熬资历慢慢爬，招聘广告说可以给对应的职级但入职后没有兑现承诺。最近一份工作也是如此，和我一同入职的人有一个也是 8 年经验被压到初级。自己还有产品思维，能考虑到整个产品的生命周期，架构设计错误、需求设计好坏，能否解决用户痛点，存在什么风险我都能判断出来，什么架构好该怎么做都知道，但因僵化的流程无法发挥，能力被低估。

目前最头疼的问题还是垂直经验，即同类项目的开发经验，中高级 Golang 开发需要架构经验和主导开发项目的经验，这些都没有。请问一下如何突破垂直经验限制转型 Golang 开发？