一个小小评论区惊现阿里和腾讯的两位大佬！他们干到退休应该是没什么问题，那你们呢？文中还有粉丝投稿的一次完整面试的面经，速来围观。

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

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

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

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

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

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

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

万兴实习面试

一面（Hr）

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

二面（技术）

1. go defer顺序

类似于栈，先进后出

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

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

一、分库

1. 垂直分库

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

<li>水平分库

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

二、分表

1. 垂直分表

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

<li>水平分表

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

<li>谈谈你对docker的理解（参考中阳哥docker那篇文章）

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

1. 隔离应用

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

<li>便于部署迁移

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

<li>优化资源利用

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

<li>支持版本控制与回滚

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

<li>促进开发运维协作

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

<li>适合微服务架构

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

<li>助力 CI/CD

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

<li>Grpc和http的区别

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

<li>协作开发时，不同人员的go版本不同如何解决

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

<li>Prtobuf文件过多过长时候该如何管理

1. 分包与分组
   • 将相关功能或模块的消息定义分组到不同的 Protobuf 文件中。
   • 例如，将用户相关的消息定义放在 <code>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 中供其他文件引用。

<li>GMP模型

https://juejin.cn/post/7384303275376230411

可以看看这个，我自己总结的

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

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

<li>

如何进行版本管理（git）

2. Map是否安全

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

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

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

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

<li>个人项目相关（较多较细）
2. Kafka

三面（综合面）

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

欢迎关注 ❤

我的文章都首发在同名公众号：王中阳

需要简历优化或者就业辅导，可以直接加我微信：wangzhongyang1993，备注：博客园