现在有什么赛道可以干到退休？

前些天发现了一个巨牛的人工智能学习网站，通俗易懂，风趣幽默，忍不住分享一下给大家：点击跳转到网站 ，对人工智能感兴趣的小伙伴可以点进去看看。

最近，一则“90后无论男女都得65岁以后退休”的消息在多个网络平台流传，也不知道是真是假，好巧不巧今天刷热点的时候又看到一条这样的热点：现在有什么赛道可以干到退休？

点进去看了几条热评，第一条热评说的就是：

“除了体制内，哪里可以干到65岁退休？”

结果后面就有两个人发了两张截图截图，内容分别是“入职阿里巴巴15周年的祝福”和“入职腾讯14周年的祝福”，真的是让人羡慕嫉妒恨呐，他们稳定干到退休肯定是没问题…

那你呢？你现在的“赛道”可以干到退休吗？

想听听大家对这件事的看法，欢迎大家在评论区讨论！

当然看这些东西就图一乐哈，最重要的还是学习，下面就分享一下粉丝投稿的万兴实习面经。

万兴实习面试

一面（Hr）

1. 自我介绍
2. 你认为你的个人优势是什么
3. 谈谈你的工作经历或实习经验
4. 说说你个人的优点
5. 你对这个行业未来的看法
6. 了解Ai吗，对ai的看法

二面（技术）

1. go defer顺序

类似于栈，先进后出

2. mysql如何储存大量数据，分库存分表的建议和看法（没答出来）

在 MySQL 中处理大量数据时，分库分表是一种常见的策略：

一、分库

1. 垂直分库

• 按照业务模块将不同的数据表存储在不同的数据库中。例如，将用户相关的数据表放在一个库，订单相关的数据表放在另一个库。
• 优点：可以降低单个数据库的复杂度，提高特定业务模块的性能和可用性。
• 缺点：跨库关联查询变得复杂，需要通过应用层来处理。

2. 水平分库

• 将数据按照某种规则（如用户 ID 取模）分布到多个数据库中。
• 优点：可以有效应对数据量的增长，实现分布式存储和负载均衡。
• 缺点：数据的分布规则需要精心设计，数据迁移和扩容相对复杂。

二、分表

1. 垂直分表

• 将一个表中不常用的字段、大字段或者长度较长的字段拆分到另一个表中。例如，将商品表中的详细描述字段拆分到单独的表中。
• 优点：减少表的宽度，提高查询性能，便于维护。
• 缺点：增加了表关联的操作。

2. 水平分表

• 按照一定的规则（如主键值取模、按时间范围等）将一个表的数据拆分到多个表中。
• 优点：可以解决单表数据量过大的问题，提高查询效率。
• 缺点：同样存在数据分布规则设计和跨表查询的复杂性。

2. 谈谈你对docker的理解（参考中阳哥docker那篇文章）

Docker 是一种重要的技术，理解如下：

1. 隔离应用

• 把应用和其依赖打包在独立容器中，彼此隔离不干扰。
• 像 Web 应用和数据库应用能在同一主机上互不影响。

2. 便于部署迁移

• 容器包含应用所需一切，能在不同环境快速部署，无视环境差异。

3. 优化资源利用

• 能更精细分配资源，多个容器可共享主机资源。

4. 支持版本控制与回滚

• 对容器镜像能版本控制，出问题可回滚。

5. 促进开发运维协作

• 开发环境与生产一致，减少问题。

6. 适合微服务架构

• 每个微服务可打包成容器，方便独立操作。

7. 助力 CI/CD

• 与相关工具链集成，实现自动化流程。

2. Grpc和http的区别

1. 性能
   • Grpc 通常在性能方面表现更优，因为它使用二进制协议，数据传输效率高。
   • Http 一般使用文本格式，数据量相对较大。
2. 连接方式
   • Grpc 支持长连接，能减少连接建立的开销。
   • Http 常见的是短连接，每次请求都要重新建立连接。
3. 数据格式
   • Grpc 基于 Protocol Buffers 定义数据格式，具有高效的序列化和反序列化能力。
   • Http 可以使用多种数据格式，如 JSON、XML 等。
4. 流处理
   • Grpc 对双向流和服务器流的支持较好。
   • Http 在流处理方面相对较弱。

2. 协作开发时，不同人员的go版本不同如何解决

1. 统一版本
   • 确定一个共同的 Go 版本，要求所有开发人员安装和使用该版本。
   • 可以通过项目规范和文档明确指定。
2. 使用工具管理
   • 利用版本管理工具，如 go.mod 和 go.sum 。
   • 这些文件可以指定项目所依赖的特定 Go 版本和模块版本，确保不同开发者在拉取代码时能够获取到一致的依赖环境。
3. 容器化开发环境
   • 使用 Docker 等容器技术创建统一的开发环境。
   • 在容器中配置好指定的 Go 版本和相关依赖，开发人员在容器中进行开发，避免本地环境差异。

2. Prtobuf文件过多过长时候该如何管理

1. 分包与分组
   • 将相关功能或模块的消息定义分组到不同的 Protobuf 文件中。
   • 例如，将用户相关的消息定义放在 user.proto ，订单相关的放在 order.proto 。
2. 目录结构规划
   • 创建清晰的目录结构来组织 Protobuf 文件。
   • 可以按照业务模块、功能类型等划分不同的目录。
3. 提取公共部分
   • 如果有多个文件中存在重复或相似的定义，提取这些公共部分到单独的 Protobuf 文件中，然后其他文件进行引用。
4. 版本控制
   • 利用版本控制系统（如 Git）来管理 Protobuf 文件的变更历史。
5. 文档注释
   • 在 Protobuf 文件中添加详细的注释，说明每个消息的用途、字段含义等，方便理解和维护。
6. 定期审查与重构
   • 定期对 Protobuf 文件进行审查，删除不再使用的定义，优化复杂的结构。

例如，一个大型电商项目可以将商品相关的 Protobuf 文件放在 goods/ 目录下，包括 goods_info.proto 、 goods_comment.proto 等。对于一些通用的错误码定义，可以提取到 common/error_code.proto 中供其他文件引用。

2. GMP模型

https://juejin.cn/post/7384303275376230411
可以看看这个，我自己总结的

2. 为什么选择go,go语言优势，打算做哪方面的开发

Go 语言有诸多优势，如语法简洁高效，便于学习和编写；并发支持强大，goroutine 和 channel 让并发编程轻松；编译速度快，利于快速开发；内存管理有自动垃圾回收；跨平台性好；性能出色，能满足高性能需求；标准库丰富，涵盖众多领域。这些优势使其在云计算、后端开发、网络编程等领域广泛应用。

2. 如何进行版本管理（git）

3. Map是否安全

在 Go 语言中，内置的 map 不是并发安全的。

如果在多个 goroutine 中同时对一个 map 进行读写操作，可能会导致不可预测的结果，例如数据竞争、程序崩溃等。

例如，如果一个 goroutine 正在对 map 进行写入操作，而另一个 goroutine 同时在读取或删除元素，就可能出现问题。

为了在并发环境中安全地使用 map ，可以使用一些并发安全的替代方案，比如使用 sync.RWMutex 来加锁保护对 map 的操作，或者使用第三方库提供的并发安全的 map 实现。

2. 个人项目相关（较多较细）
3. Kafka

三面（综合面）

1. 是否使用过ai,对大模型的看法，大模型对程序员有什么帮助？
2. 如果你要进行一个项目开发的话，流程该怎么样
3. 对于Go的界面化不够友好，该怎么解决
4. 在项目开发时候，前后端开发有分歧该如何解决
5. 对于go未来的发展你怎么看，使用哪个版本的go,各个版本间你是怎么看的
6. 个人爱好，职业发展

欢迎关注 ❤

我们搞了一个免费的面试真题共享群，互通有无，一起刷题进步。

没准能让你能刷到自己意向公司的最新面试题呢。

感兴趣的朋友们可以加我微信：wangzhongyang1993，备注：csdn面试群。