我刚入嵌入式这一行的时候，被环境问题折磨到怀疑人生。组里有个新同事，连续三天卡在同一个报错上，他在Windows里装了五六个版本的arm编译器，又装了一堆看起来关联又没什么用的依赖，最后连一个最简单的printf程序都编不出来。我过去看了一眼，问题非常简单：他用的qmake是x86版，却想编ARM目标。
做嵌入式Linux开发，尤其涉及Qt图形界面的时候，最大的门槛往往不是算法多难、协议多绕，而是开发环境这关没过。今天这篇文章就是想给嵌入式开发者把最常被问到的几个问题一次说明白：应用层开发算不算嵌入式、环境到底该选Windows还是Ubuntu、Linux+Qt5怎么从零跑通，以及汽车电子嵌入式开发这样的细分方向怎么入门。刚入坑的朋友、从单片机转过来的朋友、写了一阵子应用层但总觉得差点意思的朋友，都可以照着自己项目的情况参考，不用完全照搬，但思路是可以通用的。
1. 先搞清楚：应用层开发算不算嵌入式开发
这个话题几乎每隔一段时间就会在技术群里吵一轮。很多人在招聘网站上看到“嵌入式软件开发”的JD，点进去一看要求的是C/C++、Linux系统编程、Qt界面、多线程、网络通信，偶尔还要会点数据库，怎么看怎么像“纯软件”，于是开始怀疑：我到底是不是在做嵌入式？
1.1 招聘JD里的“嵌入式开发”到底指什么
从岗位画像来看，市面上的“嵌入式软件工程师”其实覆盖了完全不同的几种工作内容。最容易被误解的就是嵌入式Linux应用开发工程师，这类岗位日常写得最多的就是业务逻辑、界面交互、协议对接，代码跑在开发板的Linux系统上，而不是直接操作寄存器。很多人觉得这不就是“在Linux上写普通程序”吗？跟后端开发有什么区别？
区别其实挺大的。后端程序跑在服务器上，你不需要关心内存映射、没有触摸屏、不需要处理GPIO中断、更不需要把程序部署到一台只有256MB内存的板子上还保证不崩溃。嵌入式应用层开发虽然用的是Linux系统调用，但你要时刻清楚代码最终跑在什么硬件上，外设是怎么接入的，总线速率是多少，用户空间和内核空间的边界在哪里。遇到一次串口丢数据、触摸屏误触发、交叉编译出来的程序在板子上起不来，你就明白这一行和普通软件开发之间隔着多厚的知识墙。
所以我的结论很直接：应用层开发是嵌入式开发链条中的一节，而且是大多数人职业生涯的起点。它不像驱动和内核开发那样贴近硬件，但它是从“会写代码”到“能交付一套嵌入式产品”之间最务实的一步。只写业务不动硬件的应用开发确实容易走窄，但完全可以在这个基础上往底层钻。
1.2 嵌入式开发的技能坐标系：应用层、驱动层、内核层
为了把问题说透，可以用一张对照表把嵌入式开发的主要层级拆开看：
| 层级 | 典型任务 | 核心技能 | 出错后的排查深度 |
|---|---|---|---|
| 应用层 | 界面、业务逻辑、网络协议、数据处理 | C/C++、Linux系统调用、Qt/GTK、多线程、Socket | 一般到Linux API和板级外设接口为止 |
| 驱动层 | 外设驱动、中断处理、DMA、设备树 | 内核模块、platform驱动框架、寄存器读写 | 要看原理图、芯片手册、总线协议时序 |
| 内核层 | 内核移植、调度、内存管理、文件系统 | 内核源码、汇编、硬件架构知识 | 需要跟踪内核日志、崩栈回溯、汇编级排查 |
从学习周期来看，应用层上手最快，两三个月就能写出像样的程序；驱动层需要啃芯片手册，半年到一年才能独立处理一类外设；内核层就更不用说，没个两年持续投入很难说有把握。
但有一个点很容易被新手忽略：这三个层级不是割裂的，而是同一条链路的不同深度。应用层调read()读一个按键，最终要经过虚拟文件系统、驱动、GPIO控制器，才能变成引脚上的电平变化。好的应用开发者不一定写得来驱动，但至少要知道哪一层可能出问题，能带着驱动同事快速定位。
1.3 嵌入式Linux应用开发为什么吃香
最近几年智能硬件、工业HMI、充电桩、医疗终端、电力采集设备这类产品爆发式增长，而这些设备几乎都有一个共同点：需要屏幕、需要联网、需要稳定的人机交互。在这个背景下，Linux+Qt5几乎是事实上的标准组合。
嵌入式Linux应用开发的能力模型恰好卡在一个很舒服的位置：它不像内核开发那么高门槛，但又比纯单片机开发有更广的适用面。团队里可以没有内核专家，但一定需要能把界面做出来、把业务逻辑和协议跑通的人。很多产品公司招聘时并不要求你会写驱动，只要你懂Linux环境、会用Qt、能解决板子上的常见问题，就能撑起一个项目。
这条路线也是为数不多“既能接触硬件、又不至于天天对着寄存器”的路径。对从单片机转过来的朋友来说，它是技能体系的一次升维；对从纯软件转过来的人来说，它又是理解硬件最好的入口。至于有些人担心“应用层天花板低”，我觉得这是误解——天花板从来不是技术栈决定的，是你愿不愿意沿着报错信息往底层多翻几层决定的。
2. 开发环境选型：别再在Windows和Ubuntu之间反复横跳
网上常搜到“windows18-hd19嵌入式开发”这种词，我看大概率不是指某个真实存在的开发板，而是很多人折腾开发环境时的真实写照——一会儿在Windows下配置，一会儿又切到Ubuntu的某个版本，来来回回折腾，最后卡在环境上寸步难行。如果你也处于这种状态，这一节就是为你写的。
2.1 Windows亲历的坑：交叉编译、路径权限、串口驱动三大难题
先声明，我并不是说Windows完全不能做嵌入式开发，Keil、IAR这些MDK生态在Windows上就非常成熟，做单片机开发毫无问题。但一旦进入嵌入式Linux领域，Windows的体验就急转直下。
首选是交叉编译工具链。GCC这套东西在Linux上是一等公民，在Windows上要么用Cygwin/MSYS2这套模拟环境，要么找别人打好的Win版工具链，版本参差不齐，编译出来的东西有时就是不对。我遇到过最典型的一个坑：同一个工程，在Windows下编出来的二进制放到板子上报Exec format error，但同一份源码在Ubuntu下编出来就正常，排查到最后发现是工具链的链接配置默认指向了宿主机的库路径。
其次是文件系统的水土不服。Windows的路径分隔符是反斜杠，Linux是正斜杠；Windows文件系统不区分大小写，Linux严格区分；Windows换行符是\r\n，Linux是\n。这些看似不起眼的差异，在Makefile、交叉编译器脚本、SDK自动构建流程里会被无限放大，经常出现脚本在Linux上跑得好好的，拷到Windows下就各种诡异报错。再有就是USB串口和调试器的驱动问题。板卡的USB转串口芯片在Windows上经常要手动装驱动，而且不同芯片驱动还互相打架。
2.2 为什么芯片厂商SDK和开源工具链默认围绕Ubuntu
很多新手会问一个很实在的问题：为什么就不能官方出一个Windows版的开发套件？这里面的根本原因是芯片厂商和开源社区构建生态时，所有开发、测试、发布流程都是基于Linux的。
以最常见的交叉编译工具链为例，GCC的ARM版本本身就是Linux工具链体系中的一部分，SDK里的构建脚本默认用bash执行，Yocto、Buildroot这类根文件系统构建工具更是只能在Linux环境下完整运行。芯片厂商在发布SDK时，通常在Ubuntu 18.04或20.04上验证全部流程，所以SDK文档里写的第一条往往是“建议使用Ubuntu 18.04 LTS”。你要是用Windows，就得自己去解决脚本依赖、符号链接、权限模型这些问题，等于同时维护一套SDK文档之外的兼容层，成本实在太高。
我经常打一个类比：你要在一条产线上做加工，厂家给的工艺文件是按标准车间写的，你却非得先自己改造车间再去套这个工艺，折腾半天不说，最后产品还不一定达标。与其这样，不如直接进标准车间干活。
2.3 虚拟机、双系统与WSL的取舍建议
那么在Ubuntu环境的具体形态上，怎么选才合理？我也算把几种方案都用了一遍，直接说结论：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 虚拟机（VMware/VirtualBox） | 和Windows共存，随时切换，快照方便 | 性能有损耗，USB设备转发偶尔抽风 | 新手入门、临时跑SDK构建、需要看Windows资料 |
| 双系统 | 性能完全释放，设备直通无兼容问题 | 切换系统要重启，分区管理有风险 | 确定长期做、需要大量编译、调试器稳定接入 |
| WSL/WSL2 | 轻量，启动快，目录互通 | 对USB串口、JTAG调试器支持很折腾 | 只写纯应用层代码、不直接接板子的场景 |
我自己目前的方案是主力机用Ubuntu 20.04，同时在虚拟机里保留一个Ubuntu 18.04专门跑那些只支持老版本系统的SDK。桌面环境用Xfce，跑Qt Creator和Chromium都不卡，编译时用满8核，体验和裸机差别不大。
这里要特别提醒一点：如果你要接开发板调试，虚拟机里务必把网络模式设为桥接，让开发板直接和虚拟机处于同一网段，否则SSH连接、NFS挂载、gdbserver调试都会因为网络隔离变得无比别扭。
3. 实操：从零搭建Linux+Qt5交叉编译开发环境，跑通你的第一块开发板
环境选型聊完，接下来是整篇文章最有价值的部分——完整跑通一套Linux+Qt5交叉编译环境。我在这个环节踩过的坑比写业务代码多十倍，所以下面的步骤会写得非常具体，每一步都会解释“为什么这么做”。
3.1 宿主机准备：镜像、源、基础工具
第一步是装好Ubuntu系统。如果你用的是SDK自带虚拟机镜像，这一步可以跳过；如果你是手动安装，建议下载Ubuntu 18.04.6 LTS或20.04.6 LTS的桌面版镜像。版本的选择逻辑很简单：SDK文档里写了哪个版本，就优先用哪个版本；没写的话用20.04，软件源里的包更新，兼容性也好。
安装完成后先干三件事：换软件源、更新系统、装基础工具包。国内网络环境下，把apt源换成清华或阿里云的镜像能省下大量的下载等待时间。基础工具包我一般按这个命令装：
sudo apt update sudo apt install -y build-essential git vim ssh net-tools \ cmake libncurses5-dev libssl-dev \ minicom cutecom file tree其中build-essential是编译必需的，包括gcc、g++、make；minicom和cutecom是串口调试工具，前者命令行，后者图形界面；file和tree是排查文件类型和目录结构的利器。装完后建议把宿主机的SSH服务开起来，因为后面Qt Creator要反向连到宿主机执行rsync部署。
3.2 拿到交叉编译工具链：只信板卡SDK
交叉编译工具链是整个环境的核心，最稳妥的来源是板卡厂商SDK目录里自带的那个，而不是自己在网上随便下载。不同厂商的工具链版本差异很大，有的SDK用Linaro GCC 6.2，有的用gcc-arm-10.3，版本不匹配的典型表现就是链接时一堆undefined reference，或者编译出来的程序运行时crash。
假设SDK里给的是arm-linux-gnueabihf工具链，解压到/opt目录后，先确认它的bin目录下真的有arm-linux-gnueabihf-gcc这个文件，然后把工具链路径加入环境变量：
export PATH=/opt/arm-gcc/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf/bin:$PATH验证是否生效：
arm-linux-gnueabihf-gcc -v接着编译一个最简单的hello.c，用file命令检查输出文件格式：
arm-linux-gnueabihf-gcc hello.c -o hello file hello正常情况下你会看到ARM、32-bit、ELF这类字样。如果看到x86-64，说明编译器选错了或者环境变量没生效。这一步验证特别重要，很多环境问题就是在这个环节及时暴露的。
3.3 配置Qt5运行库与qmake
Qt5的获取有两种路径：第一是SDK自带的交叉编译版本Qt库，这种最省事，库已经编好，路径通常在/opt/qt5.12.10之类的目录下；第二是自己用Qt源码交叉编译一遍，这种方式可控性高，但耗时长，还要解决依赖库裁剪问题，新手不推荐。
我强烈建议新手优先用SDK自带的Qt库。你只需要确认几个东西：qmake是否指向ARM目标、Qt库目录是否存在、插件目录里有没有linuxfb、eglfs等平台插件。验证方法是：
/opt/qt5.12.10/bin/qmake -query重点看QT_HOST_PREFIX和QT_INSTALL_PREFIX。如果QT_HOST_PREFIX显示的是宿主机的目录，但QT_INSTALL_PREFIX指向板端目录，这通常是交叉编译的正确形态；如果两个都是x86路径，说明你还是用了桌面版qmake。
如果你确实需要用源码自己编译Qt库，configure的关键参数我整理成表，一般照着这个思路配置即可：
| 配置项 | 示例 | 作用 |
|---|---|---|
| -device | linux-imx6-g++ | 指定目标平台的mkspec，对应你的芯片类型 |
| -device-option | CROSS_COMPILE=/opt/arm-gcc/.../bin/arm-linux-gnueabihf- | 指定交叉编译前缀 |
| -sysroot | /opt/arm-sysroot | 指定根文件系统路径 |
| -prefix | /usr/local/qt5 | Qt库最终安装在板子上的路径 |
| -opensource -confirm-license | — | 接受开源许可 |
| -no-xcb -no-opengl | — | 精简桌面相关依赖，减小体积 |
自己编译Qt源码头几次失败率很高，遇到问题不要硬刚，先把SDK自带的跑通，等你有余力再尝试从源码重建。
3.4 在Qt Creator里添加一套完整Kit
有了工具链和Qt库，接下来的任务是把它们整合进Qt Creator，形成一个可以直接编译、部署、调试的完整套件。很多人前面都顺利，最后卡在Kit配置上，所以这里每一步都不嫌啰嗦。
打开Qt Creator，依次操作：Tools→Options→Kits。先添加编译器：
- Compilers标签页→Add→GCC→C。名称填arm-gcc，Compiler path选工具链bin目录下的arm-linux-gnueabihf-gcc。
- 同样的方式添加C++编译器，选中g++。
然后添加Qt版本：
- Qt Versions标签页→Add，选择交叉编译库目录里的qmake，比如/opt/qt5.12.10/bin/qmake。确认版本号能正确识别。
再添加设备：
- Devices标签页→Add→Generic Linux Device。填开发板的IP地址、用户名（通常是root）、密码，然后点测试连接。这一步会通过SSH协议连接开发板，确认链路是通的。开发板最好设置固定IP，否则每次重新分配会让后续配置全部失效。
最后新建Kit：
- Kits标签页→Add，名称填arm-linux-dev。Compiler下拉分别选刚才加的gcc和g++，Qt version选交叉编译版qmake，Device type选Generic Linux Device，Sysroot填工具链对应的sysroot目录。其他保持默认。
配置完之后，新建一个Qt Widgets Application，在构建套件里选中这套Kit，直接点击运行。Qt Creator会自动把编译产物通过scp推到开发板，远程启动程序，你就能在板子的屏幕上看到一个Qt窗口了。如果这一步能跑起来，说明整个环境已经真正打通。
4. 汽车电子嵌入式开发：高门槛赛道的核心知识与入门路线
说完通用环境，再聊聊嵌入式领域里一个薪酬和门槛都很突出的方向——汽车电子嵌入式开发。这个方向近几年热度很高，但很多人对它的认知停留在“做汽车里的小电脑”这种模糊层面，导致入行前心里没底。
4.1 汽车电子软件的两条主线
汽车电子嵌入式开发内部其实分得很开，大体有两条主线：传统的MCU车控方向和面向智能座舱/自动驾驶的SoC方向。
MCU车控方向主要做车窗、雨刮、BMS、车身控制器这类ECU的底层软件，技术栈聚焦在C语言和AUTOSAR架构上，强调实时性、确定性和诊断功能。这里每一条总线报文都要按规范来，不能想怎么写就怎么写，因为车辆的电控系统直接关系安全。
SoC方向则是智能座舱、仪表、ADAS域控制器，跑的是高性能处理器，系统多半是Linux、QNX或者Android，编程语言从C/C++延伸到Java、Kotlin，中间要接摄像头、激光雷达、HUD等一堆设备。这个方向更偏应用和系统，嵌入式底子和软件工程能力两个都不能缺。
汽车电子开发的特点是高可靠性要求贯穿始终，消费电子出个bug重启一下能忍，汽车上同样的bug可能牵涉到功能安全。所以这个行业对开发流程、文档、评审的要求比一般嵌入式严苛得多。
4.2 从应用层切入汽车电子的核心基础
如果你想往汽车电子方向走，无论选哪条主线，有几块基础绕不开。
第一是通信总线。CAN是汽车电子最底层的血管，你得理解CAN 2.0经典帧和CAN FD的区别，会看仲裁ID、数据段和波特率，知道总线负载怎么算。更深入的还要了解LIN总线、车内以太网。招聘时直接给你一个CAN报文让你解析，是最常见的考察方式。
第二是诊断协议。各大车厂虽然各有私有协议，但底层都基于ISO 14229（UDS诊断服务）和ISO 15765（诊断传输层）。0x10会话控制、0x22按ID读数据、0x2E按ID写数据、0x34/0x36/0x37刷写流程，这些服务码和应用逻辑最好能自己写一遍、跑一遍。
第三是AUTOSAR分层思维。你不用真的把整套AUTOSAR源码吃透，但必须理解BSW（基本软件）、RTE（运行时环境）、SWC（应用软件组件）这三层是怎么协同的，因为现代汽车软件开发的协作方式就是围绕这个模型展开的。哪怕你进去只写ASW层的逻辑，也要知道它的边界在哪。
4.3 给想进汽车电子的人三条建议
结合我自己接触过的项目和过来人的经验，给想转汽车电子的人三条建议。
第一，把C语言功底打磨到“结构体用得行云流水、内存管理从不含糊”的程度。汽车电子代码里大量使用结构体指针、回调函数、状态机，底层逻辑对内存布局极其敏感，这些基础不扎实，面试聊三轮必露馅。
第二，想办法搞一套CAN分析工具练手。有条件用CANoe当然最好，配合一个USB-CAN盒子，自己搭一个最小网络，发报文、抓报文、模拟故障，把总线上的行为吃透。没有CANoe就用开源的SocketCAN工具，在Linux下用cangen、cansend、candump这几个工具也能玩出很多花样。
第三，基于UDS协议做一个刷写或诊断的小项目。不需要真的跑在车上，可以在一个开发板或工控机上模拟ECU，用上位机实现会话控制、写入功能寻址、读取DTC故障码的流程。这个项目对汽车电子岗位的杀伤力非常大，因为它同时覆盖了协议、通信、状态机三个核心能力。
5. 新手踩坑实录：交叉编译与Qt部署常见问题排查
环境搭建过程中最耗时间的永远是排查问题。这一节我把这些年遇到的高频问题整理成速查表，每条都是能直接照着操作的。
5.1 环境类问题速查表
| 现象 | 直接原因 | 解决办法 |
|---|---|---|
| 编译产物放板子上报Exec format error | 编译成了x86二进制，不是ARM | 用file命令检查产物；确认工具链路径和qmake都指向ARM |
| Qt程序启动报could not find platform plugin | 缺少linuxfb/eglfs等平台插件 | 把插件目录拷贝到板端Qt安装目录的plugins/platforms下 |
| 运行报找不到libstdc++.so.6 | 板端文件系统缺工具链动态库 | 把工具链的lib目录整体拷到板端，或编译时加-static |
| 中文显示为方框、乱码 | 板端没有中文字体 | 拷贝wqy-microhei等字体到板端Qt字体目录，刷新字体缓存 |
| 触摸屏点击没反应 | 触摸事件设备号不对或没设环境变量 | 确认/dev/input/eventX，设置QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS |
| Qt Creator运行按钮直接失败 | 设备连接配置错误或网络不通 | Devices里重新测试连接；检查IP和桥接网络 |
| gdb断点打不上 | 板端没有gdbserver或路径不一致 | 在板端启动gdbserver :1234 ./app，宿主机用arm-gdb连接 |
| 编译特别慢 | 虚拟机分配核数不足或磁盘IO差 | 虚拟机设置里调高CPU核数，Qt源码编译用-j参数 |
5.2 三个省时间的土办法
第一，拿到工具链后，把工具链的lib目录整个同步到开发板。很多所谓“程序在板子上跑不起来”的问题，根子就是板端文件系统太精简，缺了动态库。你与其挨个库去拷，不如一次性把工具链的lib/arm-linux-gnueabihf目录同步过去，再执行ldconfig，能解决一大片运行时loading shared libraries的错。
第二，写一个env.sh脚本，把所有环境变量固化下来。每次打开新终端source一下，就能自动把PATH、CROSS_COMPILE、SYSROOT、LD_LIBRARY_PATH这些全部设置好。别老是手动往终端里粘路径，粘十次必有一次漏。我第一次把工具链从一台机器搬到另一台机器时，就因为漏了QT_PLUGIN_PATH这个变量，浪费了几乎一个晚上排查一个看起来像代码bug的问题。
第三，板子上跑Qt程序时，习惯写一个启动脚本而不是直接敲命令。脚本里显式设置好LD_LIBRARY_PATH、QT_QPA_PLATFORM、QT_QPA_FB_DRM_BACKEND等环境变量，再启动程序。这样每次改动都只改脚本，不会因为环境变量没带上而出诡异问题。启动脚本也要配合板端/etc/ld.so.conf.d/下的配置文件一起用，把Qt库目录加入系统库搜索路径。
6. 下一步怎么走：嵌入式Linux应用开发学习路径
环境跑通只是起点，真正决定你能走多远的是后面的持续学习。这里我整理一条适合大多数人的路径，按阶段逐步推进。
6.1 五个阶段的路线图
第一阶段是Linux操作基本功。目标不是会敲命令，而是能在一个无桌面的最小系统里完成文件操作、进程管理、网络配置、脚本编写这些日常操作。衡量标准是给你一台空系统，你能在一个小时内把它配置成可以开发的状态。
第二阶段是Linux系统编程。围绕文件IO、进程、线程、信号、IPC、Socket几个核心主题，写出至少一个多线程网络通信的服务端和客户端。这个阶段的练习重点不是功能实现，而是稳定性——比如高并发下内存会不会涨、线程间变量有没有竞态。
第三阶段是板级外设应用。把GPIO、UART、I2C、SPI、PWM这些接口通通用一遍，用应用层程序去操作它们，理解设备节点read/write/ioctl这套用户空间接口。这个阶段你才真正做到“应用层和硬件握手”。
第四阶段是Qt图形界面开发。从QWidget开始，再切入Qt Quick/QML，配合触摸屏完成工业HMI常见的页面跳转、数据刷新、告警弹窗。重点掌握在嵌入式环境下的资源受限优化，比如字体发布、图片格式选择、启动速度优化。
第五阶段是可选的纵深方向。如果需要往底层走，可以学设备树、kernel模块编写、中断下半部、DMA等内核知识；如果往应用系统走，可以学Buildroot/Yocto定制根文件系统，理解镜像构建的完整链路。
6.2 适合写进简历的实战项目清单
很多朋友学了东西不知道怎么整理成项目经验。我提供一个选题思路：每个项目都要覆盖“板卡+外设+协议+界面/云端”的完整链路，而不是只做一个闪烁LED或者一个计算器界面。下面几个方向都有代表性：
| 项目主题 | 覆盖技术点 | 加分项 |
|---|---|---|
| 环境监测终端 | Qt+SQLite+传感器（I2C/SPI）+MQTT | 数据曲线展示、断线续传 |
| 智能家居中控面板 | Qt Quick+Modbus/TCP+触摸屏适配 | 多页面切换、场景联动 |
| CAN总线分析工具 | SocketCAN+解析引擎+上位机 | 支持波特率自动识别、故障帧挑出 |
| 远程升级工具 | UDS刷写+CRC校验+断点续传 | 支持多通道同时刷写 |
| 工业HMI控制面板 | 触摸屏+PWM背光+状态机 | 报警事件记录、掉电恢复 |
挑一到两个项目做深做透，把调试过程、踩坑记录、性能优化写清楚，比堆十个半成品有说服力得多。面试官最看重的不是你会多少名词，而是你真正独立解决过多少问题。
我个人在实际操作中的体会是：嵌入式开发拼的从来不是智商，而是谁能更早把自己的环境收拾利索，谁就有更多精力扑在真正的问题上。很多人不是学不会，是被环境问题磨掉了热情。所以我会劝新人，第一年宁可慢，也要把工具链、调试器、部署脚本这些基础自动化做扎实。每次报错不要急着到处问，先自己拆解出错信息是在哪一层冒出来的。等你某一天发现自己不再纠结“Windows还是Ubuntu”“编译器是不是对上了”这种低级问题时，那种流畅感才是真正入行的标志。如果这篇文章能帮你在环境这块少走几个月的弯路，我觉得就值了。
