点点互动哪些部门值得去？

公司：9377游戏岗位：后端开发工程师方向：Java 后端 / 游戏后端1. 自我介绍答案思路• 学校/专业/毕业时间• 技术栈：Java、SpringBoot、MySQL、Redis、中间件等• 项目亮点：高并发、文件上传、分布式任务、性能优化• 求职意向：后端开发，长期稳定发展2. 是否有考研考公的打算？答案目前没有考研、考公计划，专注于就业，希望在企业里深耕技术，长期稳定发展，和公司一起成长。3. 怎么去选择服务器的？答案• 根据业务场景：CPU 密集型选高 CPU，I/O 密集型选高内存/高带宽• 根据并发量：QPS、连接数、带宽需求• 成本与性价比：云服务器按需扩容，优先ECS/容器• 游戏后端关注：低延迟、高可用、多区域部署4. 怎么进行冗余存储，还有别的办法吗？答案• 冗余存储：主从、副本、多副本机制• 方案：1）副本集：一主多从，故障自动切换2）分布式存储：MinIO、HDFS、OSS 多副本3）异地多活：跨机房容灾• 其他：RAID 磁盘阵列、冷热分离、备份策略。5. 断点续传怎么做？答案1. 前端分片：大文件切分成小块2. 每个分片带唯一标识：文件 hash + 分片索引3. 后端记录已上传分片，返回未上传列表4. 前端只传未完成分片5. 全部传完后端合并分片6. 怎么获取文件分片或大小？答案• 前端：通过 File 对象的 size 获取总大小，计算分片数量与偏移• 后端：通过请求头/参数拿到总分片数、当前分片、文件MD57. 上传文件用到哪些系统调用？请求头格式？答案• 系统调用：open、read、write、close• 请求头：Content-Type: multipart/form-data• 携带：Content-Length、Content-Range（断点续传）8. 怎么解决 OOM 问题？答案1. 排查：dump 内存，看 GC、大对象、内存泄漏2. 优化：◦ 避免无限创建线程/大集合◦ 池化：线程池、连接池、对象池◦ 及时释放资源，关闭流、连接3. JVM 参数：调整堆内存，合理设置 GC 策略9. 下载很大的 Excel 怎么办？答案• 流式写出：不一次性加载到内存，边生成边下载• 分页/分批次：按条数分批导出• 异步生成 + 下载：后台生成文件，返回下载链接10. ThreadPool 如何优化接口时间？答案• 同步改异步，并行执行多任务• 避免重复创建销毁线程，降低开销• 控制并发数，防止线程过多导致 CPU 飙高/阻塞• 适用于：批量处理、消息推送、日志上报等11. XXL-JOB 如何保证数据一致性？答案• 执行器幂等设计：重复执行不影响数据• 任务失败重试 + 告警• 调度中心分布式锁，避免多节点重复执行• 执行日志可追溯，支持手动处理失败任务12. MySQL 和 Redis 如何保证数据一致性？答案• 方案：先更 DB，再删缓存• 避免：先删缓存再更 DB 导致脏数据• 最终一致：◦ 延时双删◦ 分布式事务/消息队列保证最终一致• 缓存过期兜底13. 常用索引有哪些？答案• 主键索引、普通索引、唯一索引• 联合索引、覆盖索引• 全文索引（文本搜索）14. InnoDB 数据结构 & 存储格式？答案• 数据结构：B+ 树• 存储引擎格式：◦ 行格式：Dynamic/Compact◦ 表空间：系统表空间、独立表空间（ibd）

📍面试公司：广东广凌科技有限公司🕐面试时间：2026/3/20💻面试岗位：java开发实习生❓面试流程：开局二话不说先填表随后笔试：一共33道题，限时40分钟，题目整体难度适中，不确定的在6题左右，大概包含的是mysql，jvm，spring等等面试部分:1.当两张表分别是一对多或者多对多的关联关系，如何将两张表进行关联的。（这里答的分别是设置外键和设计中间表）2.Spring的事务失效的场景(这一块其实了解不多，但当时恰好问了我唯一会的一个点，异常被try-catch捕获但未重新抛出，所以事务失效了，操作不会回滚)3.spring事务的实现原理是什么(我承认这一块给我直接干懵圈了，就支...

相信准备从事软件测试的小伙伴，面试时经常会遇到这个非常令人困扰的问题。所以今天我想结合自己的理解，聊聊我对这个问题的看法。首先，面对这种问题，我们真正要做的，不是去猜面试官到底想考察什么，而是把自己真正代入到对应的工作场景里。最好的方式，就是结合你的真实实习经历或者团队项目去理解。你可以想象这样一个场景：你按照团队当前的需求文档和测试标准去执行测试，结果发现系统表现和预期不一致，于是提了一个 Bug；但开发看完之后反手来一句：“这不是 Bug。”这时候你该怎么办？没有实习经历的小伙伴，或者项目一直是自己独立开发、独立测试的人，看到这种问题可能会很疑惑，甚至会觉得有点像左右脑互搏：要么第一反应是“这个开发不专业”，要么就是“是不是我测试工作没做好”。但实际上，这两种理解很多时候都不准确。真正做过实习、尤其是在中小公司待过的小伙伴，对这种情况一般都不会太陌生。因为现实里开发“不认 Bug”，很多时候并不是说他连最基本的底层逻辑错误都不承认——如果真到了这种程度，那确实就不是正常协作问题了。更常见的情况是：你发现的并不是那种会直接影响主流程、核心业务、系统正确性的重大缺陷，而是一些可优化、也可以暂时不优化的问题。比如说，公司表面上模仿大厂流程，制定了一套比较完整的需求文档和测试标准；但实际运行过程中，团队早就已经默认按另一套业务规则在长期稳定运转了。你作为临时加入的新测试，是严格按照文档去测的，所以发现了不一致，这其实很正常。又或者说，公司的业务标准已经变化了，但测试文档没有及时更新；这时候你按旧标准提 Bug，本质上也未必是你错，更未必是开发工作没做好，而是标准同步本身出了问题。所以这种时候，你当然不能上来就把问题理解成“开发不专业”，也不能一发现对方不认就立刻怀疑自己是不是出错了。真正成熟一点的处理方式，应该是先把这个问题放回到业务和标准里看。对于前面这种很常见的情况，实际工作里大家往往会很快接受公司真实运行的那套规则，不再拘泥于纸面标准。但如果你在面试里直接说“那我就接受了”，面试官往往又会觉得你这个测试没有原则。所以更合适的表达方式其实是：先和开发充分沟通，确认分歧到底来自哪里——是需求理解不一致、文档同步不及时，还是业务规则已经发生变化；然后把问题做好记录，根据影响范围将其归类为待优化项或者低优先级问题，同时推动测试标准和实际业务规则对齐。如果后续开发进行了优化，那就再做回归验证后关闭；如果最终确认现阶段不影响核心链路，也可以明确记录原因和处理结论，避免后面重复争议。回到“你认为是 Bug，开发不认为是 Bug 怎么办”这个问题本身，我认为比较好的回答方式应该是这样的：我在实习/项目中确实遇到过类似情况。面对这类分歧，我会先回到需求文档、原型、业务规则和实际场景中确认判断依据。如果与开发、产品/策划沟通后发现问题本质上是标准文档更新不及时，或者团队实际执行标准和文档存在偏差，我会把这个问题详细记录下来，归为待优化项，并推动测试文档和业务标准尽快对齐。如果它确实存在体验或规范上的偏差，但短期内不影响主流程和核心业务，我会结合影响范围合理定级，并持续跟进后续版本是否优化；如果最终确认是真实缺陷，我也会补充复现路径、影响范围和业务风险，继续推动问题解决，并在修复后完成回归验证。这个回答的意义在于，它既能体现你在真实业务场景中的沟通和协作能力，也能体现出你作为测试的基本准则是合格的：你不是一味硬刚开发，也不是别人一句“不是 Bug”你就算了，而是会基于标准、业务和风险去判断，并且把问题处理到位。而且这个回答还有一个好处，就是它天然帮你把问题边界框住了。因为如果面试官在你已经明确说明“先核实标准、再确认归因、再记录推进”的前提下，还继续追问“那如果开发就是不认真实缺陷怎么办”，那其实已经不是在考察你会不会处理问题了，而更像是在故意把协作问题极端化。你要明白，测试不是去对开发做恶意猜想的，正如你也不能对产品、策划先做恶意猜想一样。真正成熟的团队协作，讲的是基于事实和标准推进问题，而不是先预设别人不专业、别人不负责、别人故意卡你。以上就是我对这个问题的一些个人理解，也欢迎大家补充讨论，希望这篇内容能真正帮到正在准备测试面试的小伙伴。

1. emplace_back 和 push_back 之间的区别是什么？push_back 接受一个已经构造好的对象。如果传入的是构造函数的参数，它会先调用构造函数生成一个临时对象，然后再通过拷贝构造或移动构造将该对象放入容器，最后销毁临时对象。emplace_back 利用 C++11 的完美转发（Perfect Forwarding）和可变参数模板，直接在容器的底层内存空间中原地构造对象，省去了创建和销毁临时对象的步骤。2. emplace_back 是否比 push_back 更高效？不一定总是更高效。当传入的是构造函数的参数时，emplace_back 省去了临时对象的拷贝/移动，确...