1. 从“卷王”到“滴滴”一个实习生的选择与观察去年秋天当我手握几个互联网大厂的实习offer最终选择滴滴时身边不少同学都挺惊讶。毕竟在大家的刻板印象里滴滴似乎不像某些“宇宙厂”那样是“卷”的代名词甚至在一些技术论坛上关于“滴滴技术氛围”的讨论也远不如其他几家热闹。我当时心里也犯嘀咕这个选择对吗会不会因为不够“卷”导致技术成长变慢如今作为后端研发实习生入职半年我想结合自己的亲身经历聊聊在滴滴做后端研发的真实感受以及我眼中那个“最不卷的互联网”到底意味着什么。首先得澄清“最不卷”绝不等于“躺平”或“技术落后”。恰恰相反它更像是一种更健康、更可持续的工作与成长模式。这半年来我深度参与了网约车核心交易链路的一个微服务模块开发从需求评审、技术设计、编码实现到上线运维几乎走完了全流程。我感受到的是一种“聚焦式”的成长没有无休止的、为了刷存在感而开的会议没有为了追求极致性能而过度设计的“炫技”代码更多的是围绕真实的业务问题进行扎实的技术攻关和稳定的系统迭代。这种环境对于像我这样希望打好基础、理解工业级系统如何运作的实习生来说其实是非常宝贵的。2. 技术栈与工作流在稳定与挑战之间寻找平衡很多人关心在滴滴做后端到底用些什么技术日常工作流程是怎样的。这可能是判断一个团队技术氛围最直接的窗口。2.1 主流且务实的技术选型我们团队的后端技术栈可以说是国内Java生态的一个非常经典的缩影但又紧密结合了滴滴自身的业务特点。语言与框架核心语言是Java这几乎是国内后端领域的“普通话”。主框架是Spring Boot搭配Spring Cloud体系来做微服务治理。这套组合拳的成熟度极高社区资源丰富意味着你遇到的绝大多数问题都能在网上找到解决方案或讨论。对于实习生和新入职的同学来说学习曲线相对平缓能更快地投入到业务开发中。中间件与存储消息队列用Kafka和RocketMQ缓存是Redis集群数据库以MySQL为主辅以TiDB处理部分需要分布式事务和高并发的场景。监控告警体系基于PrometheusGrafana链路追踪用的是内部基于Jaeger理念自研的系统。这些组件都是经过大规模生产环境验证的稳定性是首要考量。开发与部署代码管理用GitLabCI/CD 流水线非常完善提交代码后自动触发单元测试、集成测试、代码扫描和打包部署。容器化部署基于Kubernetes服务发布有蓝绿、金丝雀等多种策略可选。这里有个很深的体会滴滴的技术选型非常务实。不会为了追求“新潮”而盲目引入尚未成熟的技术每一项技术的引入都需要经过严格的评审评估其带来的收益性能提升、开发效率、运维成本降低是否大于迁移和学习的成本。这种务实对于保障每天承载海量订单的核心系统稳定运行至关重要。作为实习生你学到的是一套能在工业界广泛适用、经得起考验的技术体系而不是一些“空中楼阁”般的新概念。2.2 清晰且高效的工作流程我的日常工作流大致遵循“需求-设计-开发-测试-上线-复盘”的闭环。需求阶段产品经理会发起需求评审研发、测试、业务方都会参加。会议目标明确厘清业务背景、用户价值、功能边界和验收标准。我们鼓励研发同学在评审时就提出技术上的可行性问题和潜在风险避免后期返工。设计阶段对于稍复杂的需求需要编写技术设计文档。文档模板很规范要求写清楚背景、设计方案架构图、接口设计、库表设计、工作量评估、风险点、监控告警方案等。我的导师会带着我一起做设计评审这个过程是学习系统设计思维最好的机会。他会问我“为什么用Redis缓存而不是本地缓存”“这个接口的QPS预估是多少数据库扛得住吗”“万一这个服务挂了有没有降级方案”这些问题逼迫我去思考技术决策背后的业务逻辑和系统约束。开发与测试开发阶段团队有严格的代码规范CRCode Review是强制的。我的每一行代码都会被导师或组内其他资深同事Review。刚开始压力很大一个简单的PR可能会被指出十几处问题从变量命名、异常处理到并发安全。但正是这种“折磨”让我养成了写出更健壮、更可读代码的习惯。测试方面除了功能测试我们非常强调单元测试的覆盖率核心逻辑要求达到80%以上。上线与运维上线不是开发的结束而是开始。我们有完善的监控大盘服务上线后需要密切观察各项指标流量、耗时、错误率。作为服务负责人即使是实习生负责的模块也需要学习如何排查线上问题查看日志和链路追踪。我们组有个好习惯每次线上事故或预警无论大小都要写一份简短的复盘报告记录根因、处理过程和改进措施并在组内分享。这套流程听起来可能有些“传统”但它确保了项目的交付质量和系统的稳定性。对于实习生而言你能在一个规范的、工业级的流程中锻炼自己这种经历比在混乱中快速完成几个需求更有价值。3. “不卷”文化的具体体现时间、沟通与成长说滴滴“不卷”到底体现在哪些具体方面我认为可以从三个维度来看时间管理、沟通氛围和个人成长路径。3.1 对“加班”的理性态度这是最直观的一点。我们团队没有“强制加班”文化更没有所谓的“大小周”。工作时间的安排相对弹性核心要求是在关键会议如站会、评审会和协作时段在线。项目的排期通常比较合理会充分考虑到开发、测试和缓冲时间。如果因为需求变更或遇到技术难题需要加班导师和主管会主动关注并后续通过调休等方式补偿。当然互联网行业特性决定了完全“到点下班”不现实。在版本封版前、大促备战期间加班是难免的。但关键在于这种加班是有明确目标、有限度的而不是一种常态化的“表演”。我记得有一次为了一个紧急线上Bug排查到晚上十点第二天导师就让我晚点来并且明确说“今天主要就是处理一下后续别开新任务了”。这种对员工时间的尊重让人感到安心。3.2 扁平化与务实的沟通团队的沟通氛围非常扁平。无论是向我的导师一位高级架构师请教问题还是和部门总监讨论技术方案都可以直接在企业微信上约时间或者提问没有森严的层级感。技术讨论时大家就事论事观点碰撞激烈但不会人身攻击。决策往往基于数据和逻辑而不是职级。周会、月会的内容也非常务实。周会主要是同步项目进度和风险月会则是业务复盘和技术分享。很少有那种冗长而无果的“务虚会”。这种高效的沟通节省了大量不必要的精力内耗让我能把更多时间聚焦在具体的技术和业务问题上。3.3 聚焦业务价值的成长导向在滴滴技术人员的价值最终要体现在对业务的支持上。因此我们的技术方案设计第一个问题往往是“这能为业务带来什么价值提升体验、增加收入、降低成本还是保障安全” 这种强烈的业务导向迫使技术人员必须去理解自己写的每一行代码背后的业务逻辑。对于实习生公司有完善的培养体系。除了导师一对一的指导还有丰富的内部技术课程、分享会和在线文档。但更重要的是你能很快接触到有挑战性的真实项目。我入职第二个月就在导师的指导下独立负责了一个优化订单状态同步延迟的小项目。从分析现有链路瓶颈到设计基于消息队列的最终一致性方案再到编码实现和全链路压测最后上线并观察数据指标。当看到核心接口的P99耗时下降了30%时那种成就感是无与伦比的。这种“实战练兵”的机会远比听十场技术分享更有用。“不卷”在这里意味着你不需要为了“显得很努力”而去加班不需要在无关紧要的细节上过度竞争而是可以专注于解决真正的业务问题并在解决问题的过程中获得扎实的成长。4. 给未来实习生的建议如何在“不卷”的环境中最大化收获如果你也即将成为一名互联网后端实习生或者正在考虑滴滴结合我这半年的经验我有几点非常具体的建议希望能帮助你更好地适应和成长。4.1 主动出击拥抱“上下文”在大公司最大的挑战之一就是理解复杂的系统“上下文”。滴滴的业务系统尤其是核心交易链路经过多年演进已经是一个非常庞大的分布式系统。刚开始看代码你可能会一头雾水。我的建议是一定要主动。不要等着别人给你讲。拿到一个需求或任务后画图用笔画下这个需求涉及的服务、数据库、消息队列以及它们之间的调用关系。即使画得不对也是一个思考的起点。提问清单在请教导师或同事前先自己尝试回答这些问题这个功能属于哪个业务域数据从哪里来到哪里去核心的实体如订单、用户的生命周期是怎样的有哪些关键的状态影响范围是什么利用好内部工具滴滴有非常强大的内部Wiki、架构图工具和链路追踪系统。这些都是你理解系统的“宝藏”。我养成的习惯是遇到一个不熟悉的服务名先去Wiki搜一下它的职责和负责人遇到一条调用链直接用链路系统把完整的路径画出来看。当你带着自己的思考和初步的“地图”去提问时得到的指导会更有针对性你的收获也会成倍增加。4.2 深入细节但不忘全局后端开发很容易陷入“细节黑洞”纠结于某个算法的实现、某个配置项的调优。这很重要但作为实习生更需要培养全局观。在完成手头开发任务的同时不妨多问几个“为什么”为什么这个服务要拆分成微服务它和上下游服务的耦合度如何当前的数据库分库分表策略是什么是基于什么维度考虑的整个链路的容量瓶颈可能在哪里监控告警是如何设置的如果这个服务挂了公司的止损预案是什么我的导师曾给我一个任务模拟一个核心服务宕机画出可能受影响的业务方和用户体验路径并思考如何做故障隔离和降级。这个练习让我一下子对系统的脆弱性和韧性设计有了深刻的认识。多参与技术方案评审即使不是你负责的需求也能极大地拓宽你的技术视野。4.3 把“运维意识”刻在脑子里这是我认为滴滴后端文化中非常突出的一点开发要对线上负责。在这里写完代码、通过测试仅仅完成了工作的一半。你必须关心你的代码运行在线上是什么状态。日志不是用来“看”的是用来“查”的学习如何打日志。关键业务流程节点、异常捕获、耗时较长的操作都必须有清晰、结构化最好是JSON格式的日志并带上唯一的追踪IDTraceID。这样当线上出问题时你才能快速通过TraceID串联起整个请求的路径和状态。监控是你的眼睛熟悉Prometheus和Grafana了解你的服务有哪些核心指标QPS、耗时、错误率、JVM状态并为自己负责的模块设置合理的告警阈值。我实习第三个月时自己写的一个数据同步任务因为对方接口限流策略调整而失败就是通过监控告警第一时间发现并处理的。熟悉“止血”流程知道线上出问题后第一步该干什么看监控、查日志如何快速回滚如何写故障报告。公司有详细的应急预案作为责任人之一你必须了然于胸。这种强烈的运维意识能让你从一个单纯的“代码编写者”成长为一个真正的“系统守护者”。4.4 珍惜“不卷”带来的思考空间最后也是最重要的一点。正因为这里没有那么多的“无效内卷”和“焦虑氛围”你反而获得了更多深度思考的时间和空间。不要把这些时间浪费掉。你可以用这些时间啃下一个技术难点比如深入理解你用的RPC框架的底层通信原理或者研究一下Kafka是如何保证高吞吐、低延迟的。重构一段“祖传代码”在充分理解业务和影响范围后尝试用更清晰、更高效的方式重写某个小模块并拿出性能对比数据说服大家。为团队做点贡献写一个提高效率的小工具或者将你解决某个复杂问题的过程整理成一篇内部技术文章。这半年的实习我最大的感受是滴滴提供了一片土壤它不热衷于催生速成的“花朵”而是鼓励你向下扎根去吸收那些关于系统设计、关于业务理解、关于工程规范的养分。“不卷”的环境消除了很多噪音让你能更清晰地听到技术成长本身的声音。它不代表松懈而是代表一种更长期主义、更关注本质的成长路径。对于想要在后端研发这条路上走得更远、更稳的同学来说这里或许是一个值得考虑的选择。 
长河君 · 2026/8/7 5:46:42 · 阅读 1.2k 滴滴后端实习体验：务实技术栈与高效工作流下的工程师成长
1. 从“卷王”到“滴滴”一个实习生的选择与观察去年秋天当我手握几个互联网大厂的实习offer最终选择滴滴时身边不少同学都挺惊讶。毕竟在大家的刻板印象里滴滴似乎不像某些“宇宙厂”那样是“卷”的代名词甚至在一些技术论坛上关于“滴滴技术氛围”的讨论也远不如其他几家热闹。我当时心里也犯嘀咕这个选择对吗会不会因为不够“卷”导致技术成长变慢如今作为后端研发实习生入职半年我想结合自己的亲身经历聊聊在滴滴做后端研发的真实感受以及我眼中那个“最不卷的互联网”到底意味着什么。首先得澄清“最不卷”绝不等于“躺平”或“技术落后”。恰恰相反它更像是一种更健康、更可持续的工作与成长模式。这半年来我深度参与了网约车核心交易链路的一个微服务模块开发从需求评审、技术设计、编码实现到上线运维几乎走完了全流程。我感受到的是一种“聚焦式”的成长没有无休止的、为了刷存在感而开的会议没有为了追求极致性能而过度设计的“炫技”代码更多的是围绕真实的业务问题进行扎实的技术攻关和稳定的系统迭代。这种环境对于像我这样希望打好基础、理解工业级系统如何运作的实习生来说其实是非常宝贵的。2. 技术栈与工作流在稳定与挑战之间寻找平衡很多人关心在滴滴做后端到底用些什么技术日常工作流程是怎样的。这可能是判断一个团队技术氛围最直接的窗口。2.1 主流且务实的技术选型我们团队的后端技术栈可以说是国内Java生态的一个非常经典的缩影但又紧密结合了滴滴自身的业务特点。语言与框架核心语言是Java这几乎是国内后端领域的“普通话”。主框架是Spring Boot搭配Spring Cloud体系来做微服务治理。这套组合拳的成熟度极高社区资源丰富意味着你遇到的绝大多数问题都能在网上找到解决方案或讨论。对于实习生和新入职的同学来说学习曲线相对平缓能更快地投入到业务开发中。中间件与存储消息队列用Kafka和RocketMQ缓存是Redis集群数据库以MySQL为主辅以TiDB处理部分需要分布式事务和高并发的场景。监控告警体系基于PrometheusGrafana链路追踪用的是内部基于Jaeger理念自研的系统。这些组件都是经过大规模生产环境验证的稳定性是首要考量。开发与部署代码管理用GitLabCI/CD 流水线非常完善提交代码后自动触发单元测试、集成测试、代码扫描和打包部署。容器化部署基于Kubernetes服务发布有蓝绿、金丝雀等多种策略可选。这里有个很深的体会滴滴的技术选型非常务实。不会为了追求“新潮”而盲目引入尚未成熟的技术每一项技术的引入都需要经过严格的评审评估其带来的收益性能提升、开发效率、运维成本降低是否大于迁移和学习的成本。这种务实对于保障每天承载海量订单的核心系统稳定运行至关重要。作为实习生你学到的是一套能在工业界广泛适用、经得起考验的技术体系而不是一些“空中楼阁”般的新概念。2.2 清晰且高效的工作流程我的日常工作流大致遵循“需求-设计-开发-测试-上线-复盘”的闭环。需求阶段产品经理会发起需求评审研发、测试、业务方都会参加。会议目标明确厘清业务背景、用户价值、功能边界和验收标准。我们鼓励研发同学在评审时就提出技术上的可行性问题和潜在风险避免后期返工。设计阶段对于稍复杂的需求需要编写技术设计文档。文档模板很规范要求写清楚背景、设计方案架构图、接口设计、库表设计、工作量评估、风险点、监控告警方案等。我的导师会带着我一起做设计评审这个过程是学习系统设计思维最好的机会。他会问我“为什么用Redis缓存而不是本地缓存”“这个接口的QPS预估是多少数据库扛得住吗”“万一这个服务挂了有没有降级方案”这些问题逼迫我去思考技术决策背后的业务逻辑和系统约束。开发与测试开发阶段团队有严格的代码规范CRCode Review是强制的。我的每一行代码都会被导师或组内其他资深同事Review。刚开始压力很大一个简单的PR可能会被指出十几处问题从变量命名、异常处理到并发安全。但正是这种“折磨”让我养成了写出更健壮、更可读代码的习惯。测试方面除了功能测试我们非常强调单元测试的覆盖率核心逻辑要求达到80%以上。上线与运维上线不是开发的结束而是开始。我们有完善的监控大盘服务上线后需要密切观察各项指标流量、耗时、错误率。作为服务负责人即使是实习生负责的模块也需要学习如何排查线上问题查看日志和链路追踪。我们组有个好习惯每次线上事故或预警无论大小都要写一份简短的复盘报告记录根因、处理过程和改进措施并在组内分享。这套流程听起来可能有些“传统”但它确保了项目的交付质量和系统的稳定性。对于实习生而言你能在一个规范的、工业级的流程中锻炼自己这种经历比在混乱中快速完成几个需求更有价值。3. “不卷”文化的具体体现时间、沟通与成长说滴滴“不卷”到底体现在哪些具体方面我认为可以从三个维度来看时间管理、沟通氛围和个人成长路径。3.1 对“加班”的理性态度这是最直观的一点。我们团队没有“强制加班”文化更没有所谓的“大小周”。工作时间的安排相对弹性核心要求是在关键会议如站会、评审会和协作时段在线。项目的排期通常比较合理会充分考虑到开发、测试和缓冲时间。如果因为需求变更或遇到技术难题需要加班导师和主管会主动关注并后续通过调休等方式补偿。当然互联网行业特性决定了完全“到点下班”不现实。在版本封版前、大促备战期间加班是难免的。但关键在于这种加班是有明确目标、有限度的而不是一种常态化的“表演”。我记得有一次为了一个紧急线上Bug排查到晚上十点第二天导师就让我晚点来并且明确说“今天主要就是处理一下后续别开新任务了”。这种对员工时间的尊重让人感到安心。3.2 扁平化与务实的沟通团队的沟通氛围非常扁平。无论是向我的导师一位高级架构师请教问题还是和部门总监讨论技术方案都可以直接在企业微信上约时间或者提问没有森严的层级感。技术讨论时大家就事论事观点碰撞激烈但不会人身攻击。决策往往基于数据和逻辑而不是职级。周会、月会的内容也非常务实。周会主要是同步项目进度和风险月会则是业务复盘和技术分享。很少有那种冗长而无果的“务虚会”。这种高效的沟通节省了大量不必要的精力内耗让我能把更多时间聚焦在具体的技术和业务问题上。3.3 聚焦业务价值的成长导向在滴滴技术人员的价值最终要体现在对业务的支持上。因此我们的技术方案设计第一个问题往往是“这能为业务带来什么价值提升体验、增加收入、降低成本还是保障安全” 这种强烈的业务导向迫使技术人员必须去理解自己写的每一行代码背后的业务逻辑。对于实习生公司有完善的培养体系。除了导师一对一的指导还有丰富的内部技术课程、分享会和在线文档。但更重要的是你能很快接触到有挑战性的真实项目。我入职第二个月就在导师的指导下独立负责了一个优化订单状态同步延迟的小项目。从分析现有链路瓶颈到设计基于消息队列的最终一致性方案再到编码实现和全链路压测最后上线并观察数据指标。当看到核心接口的P99耗时下降了30%时那种成就感是无与伦比的。这种“实战练兵”的机会远比听十场技术分享更有用。“不卷”在这里意味着你不需要为了“显得很努力”而去加班不需要在无关紧要的细节上过度竞争而是可以专注于解决真正的业务问题并在解决问题的过程中获得扎实的成长。4. 给未来实习生的建议如何在“不卷”的环境中最大化收获如果你也即将成为一名互联网后端实习生或者正在考虑滴滴结合我这半年的经验我有几点非常具体的建议希望能帮助你更好地适应和成长。4.1 主动出击拥抱“上下文”在大公司最大的挑战之一就是理解复杂的系统“上下文”。滴滴的业务系统尤其是核心交易链路经过多年演进已经是一个非常庞大的分布式系统。刚开始看代码你可能会一头雾水。我的建议是一定要主动。不要等着别人给你讲。拿到一个需求或任务后画图用笔画下这个需求涉及的服务、数据库、消息队列以及它们之间的调用关系。即使画得不对也是一个思考的起点。提问清单在请教导师或同事前先自己尝试回答这些问题这个功能属于哪个业务域数据从哪里来到哪里去核心的实体如订单、用户的生命周期是怎样的有哪些关键的状态影响范围是什么利用好内部工具滴滴有非常强大的内部Wiki、架构图工具和链路追踪系统。这些都是你理解系统的“宝藏”。我养成的习惯是遇到一个不熟悉的服务名先去Wiki搜一下它的职责和负责人遇到一条调用链直接用链路系统把完整的路径画出来看。当你带着自己的思考和初步的“地图”去提问时得到的指导会更有针对性你的收获也会成倍增加。4.2 深入细节但不忘全局后端开发很容易陷入“细节黑洞”纠结于某个算法的实现、某个配置项的调优。这很重要但作为实习生更需要培养全局观。在完成手头开发任务的同时不妨多问几个“为什么”为什么这个服务要拆分成微服务它和上下游服务的耦合度如何当前的数据库分库分表策略是什么是基于什么维度考虑的整个链路的容量瓶颈可能在哪里监控告警是如何设置的如果这个服务挂了公司的止损预案是什么我的导师曾给我一个任务模拟一个核心服务宕机画出可能受影响的业务方和用户体验路径并思考如何做故障隔离和降级。这个练习让我一下子对系统的脆弱性和韧性设计有了深刻的认识。多参与技术方案评审即使不是你负责的需求也能极大地拓宽你的技术视野。4.3 把“运维意识”刻在脑子里这是我认为滴滴后端文化中非常突出的一点开发要对线上负责。在这里写完代码、通过测试仅仅完成了工作的一半。你必须关心你的代码运行在线上是什么状态。日志不是用来“看”的是用来“查”的学习如何打日志。关键业务流程节点、异常捕获、耗时较长的操作都必须有清晰、结构化最好是JSON格式的日志并带上唯一的追踪IDTraceID。这样当线上出问题时你才能快速通过TraceID串联起整个请求的路径和状态。监控是你的眼睛熟悉Prometheus和Grafana了解你的服务有哪些核心指标QPS、耗时、错误率、JVM状态并为自己负责的模块设置合理的告警阈值。我实习第三个月时自己写的一个数据同步任务因为对方接口限流策略调整而失败就是通过监控告警第一时间发现并处理的。熟悉“止血”流程知道线上出问题后第一步该干什么看监控、查日志如何快速回滚如何写故障报告。公司有详细的应急预案作为责任人之一你必须了然于胸。这种强烈的运维意识能让你从一个单纯的“代码编写者”成长为一个真正的“系统守护者”。4.4 珍惜“不卷”带来的思考空间最后也是最重要的一点。正因为这里没有那么多的“无效内卷”和“焦虑氛围”你反而获得了更多深度思考的时间和空间。不要把这些时间浪费掉。你可以用这些时间啃下一个技术难点比如深入理解你用的RPC框架的底层通信原理或者研究一下Kafka是如何保证高吞吐、低延迟的。重构一段“祖传代码”在充分理解业务和影响范围后尝试用更清晰、更高效的方式重写某个小模块并拿出性能对比数据说服大家。为团队做点贡献写一个提高效率的小工具或者将你解决某个复杂问题的过程整理成一篇内部技术文章。这半年的实习我最大的感受是滴滴提供了一片土壤它不热衷于催生速成的“花朵”而是鼓励你向下扎根去吸收那些关于系统设计、关于业务理解、关于工程规范的养分。“不卷”的环境消除了很多噪音让你能更清晰地听到技术成长本身的声音。它不代表松懈而是代表一种更长期主义、更关注本质的成长路径。对于想要在后端研发这条路上走得更远、更稳的同学来说这里或许是一个值得考虑的选择。