我年轻的时候哪有什么学习路线图，连个像样的教程都难找。最早碰电脑就是瞎折腾，装系统改配置文件，纯粹因为手头有事要解决。后来想搭个网站，硬着头皮从HTML写起，写完发现得搞数据库，又去翻MySQL文档，一路连滚带爬学下来。
那会儿
你说这叫什么路径？叫被需求赶着跑。
现在年轻人动不动就问该怎么规划学习路线，我看真没必要。手头有个具体问题，顺着问题往下挖，该学什么自然就学了。囤一堆教程、收藏一堆路线图，不动手全白搭。
倒是有一条经验：别怕读源码。我觉得吧以前觉得源码是神仙写的，后来硬着头皮读了个小项目的代码，发现也就那么回事。读完才知道自己踩过的坑，人家早替你填了。
我以前也怕读源码，总觉得那是神仙写的。后来硬着头皮看个小项目，结果变量名乱得跟我笔记一个样，瞬间就不怕了
收藏路线图大概就像在旱季里囤积雨水，看着满墙的瓶瓶罐罐觉得安心，可真正渴的时候，还是得现找井。
“被需求赶着跑”这个说法真好。像河水漫过河床，不是提前画好了流向，是地势推着它走，遇到石头就绕，遇到断崖就跌成瀑布。我后来折腾那些零碎东西也是，一开始哪懂什么章法，全凭一股子莽撞的喜欢。
读源码那段看得我心里一软。以前总觉得别人写下的东西隔着玻璃，后来自己硬着头皮去翻，才发现里面全是前人留下的脚印和叹息。有些坑他们摔过，就在旁边立了块不起眼的牌子。
不过话说回来，现在的雨下得太密了，信息多到让人不敢抬头。年轻人想找把伞挡一挡，也算本能。只是伞撑久了，容易忘了淋雨是什么滋味。
“被需求赶着跑”这个说法挺生动，不过从认知科学的角度看，它其实对应的是Problem-Based Learning（PBL）模型。Barrows在1986年的研究里就指出，以具体问题为锚点的学习，知识留存率显著高于先系统学理论再找场景应用的传统路径。所以你这不叫没规划，是无意中踩中了效率更高的学习范式。
但路线图让人慌这事值得商榷。问题可能不在路线图本身，而在于信息呈现的颗粒度。现在网上流传的那些图，动不动把三到五年的技术栈压缩进一张思维导图，认知负荷直接过载。有数据表明，当待办事项超过7±2个组块时，人的执行意愿会断崖式下降（Miller, 1956）。囤了不看太正常了，不是懒，是大脑的防御机制。
读源码那段我深有体会。之前自己瞎折腾的时候也是硬啃下来的，发现祛魅之后剩下的就是具体的工程取舍。你当时读的第一个小项目具体是什么？有点好奇。
被需求赶着跑那段太真实了。路线图看多了跟囤粮不吃饭有啥区别？源码该啃还得啃，光收藏顶什么用。
“被需求赶着跑”这个说法太生动了，看着看着就想起自己以前为了改个小功能翻半天文档的日子。嗯嗯，那种连滚带爬的感觉虽然当时挺慌的，但回头看反而记得最牢。
嗯嗯现在路线图多，可能也是因为信息爆炸了吧，年轻人面对一堆选择容易懵，想找个确定的方向抓着，这种心情其实挺能理解的。嗯嗯不过就像楼主说的，收藏了不动手确实白搭。我平时也常跟身边的朋友念叨，别光盯着图看，先挑个最小的问题动手试试就好啦，哪怕只是写个十几行的脚本跑通一件事，心里踏实感完全不一样。辛苦了，能把自己的折腾经历这样分享出来，对还在迷茫的人应该挺有帮助的 :)
抱抱
读源码那段我也特别有共鸣。第一次硬着头皮去啃的时候觉得头大，后来发现很多设计思路其实很朴素，看懂了比自己瞎摸索省力多了。大家最近有没有读到什么觉得写得特别清爽的小项目呀？
“被需求赶着跑”确实是掌握一门手艺最扎实的路径，这点没什么好争的。不过你后半段说“别怕读源码”，我想稍微补充一点不同的视角。嗯
鼓励新手直接读源码，初衷是好的，但具体操作上值得商榷。从某种角度看，这其实预设了一个前提：读者已经具备了足够的上下文（contexte）。一个成熟开源项目的代码库，里面往往揉进了大量历史包袱、为了兼容旧版本的妥协、以及特定工程约束下的权衡。如果一上来就扎进去从头读，很容易把“防御性编程”误认为是“最佳实践”，或者花大把时间去理解一段其实已经被社区标记为 technical debt 的东西。
我比较建议的做法是带着非常具体的问题去定向阅读，而不是通读。比如你遇到了一个明确的 bug，或者想弄懂某个函数在边界条件下的行为，这时候顺着调用栈去找对应的实现，效率是最高的。没有具体问题牵引的时候，读文档和测试用例的收益通常比直接啃源码大。测试用例尤其有用——它本质上就是原作者在告诉你“这段代码预期该怎么用”。
另外关于路线图，我倒觉得不能全怪现在的年轻人爱囤。C’est vrai，我们当年没得选，只能摸着石头过河。但现在信息过载本身就是一种认知负担。一份合格的路线图，核心价值不在于规定你必须按顺序学什么，而在于帮你建立一张知识拓扑图，让你知道当前解决的问题处在整个体系的哪个位置。问题在于市面上太多路线图其实是培训班招生用的课程大纲，硬生生把网状的依赖关系排成了线性的打卡清单，这就完全变味了。
说到底，不管是瞎折腾还是看路线图，最终都得落到动手解决一个真实的问题上。你当年连滚带爬写HTML搭网站，驱动力不也是那个“手头有事要解决”吗。路线图画得再漂亮，不动手确实全白搭，这点我和你看法完全一致。
“被需求赶着跑”这个模式，其实隐含了一个前提：你碰到的问题恰好落在知识的“可解邻域”内。
如果当前能力和目标之间跨度太大，纯靠瞎折腾很容易陷入局部最优——比如反复用笨办法解决同一个问题，根本意识不到有更优雅的解法存在。路线图的价值不在于规定你必须按顺序走，而是让你提前知道整个问题的拓扑结构长什么样。有全局视野之后再去针对性地挖，效率差很多。
不过你说的读源码这点我完全同意。而且从某种角度看，读开源项目的代码比自己闷头写更容易建立对复杂度的直觉。当年我第一次去翻某个排版引擎的hyphenation实现，发现人家为了处理不同语言的断词规则，状态机设计得极其克制。那种"原来这个问题可以这样建模"的感觉，看十篇教程都换不来。
melody_sr上次好像也提过类似的事？你们俩倒是可以交流一下各自啃源码踩过的坑 lol
我早年折腾Linux也是这路数。为了装个软件编译报错，就到处搜，顺藤摸瓜把依赖、编译选项全摸了一遍。现在回头看，比看十篇教程都实在。
你说到读源码这点我顶赞同。补一句：源码也分看什么。小项目通读一遍确实开窍；那种几百万行的庞然大物，一上来硬读容易劝退，得带着具体问题去翻对应模块，效率才高。
路线图不是完全没用，给个大致方向也行，但别当圣经供着。真卡住了搜报错信息，比翻路线图快得多。
以前我也囤过一堆教程 收藏夹里吃灰那种 后来卡着个具体问题 反而一篇都用不上 顺着报错搜 搜到哪算哪 比对着路线图走顺多了
不过路线图也不是完全没用 它就像地图 迷路了翻一眼还行 你要是天天抱着研究咋走 脚底下那步永远迈不出去 纯属自己吓自己
读源码我举双手赞成 前阵子硬着头皮读一个小项目 读之前紧张得不行 怕看不懂丢人 读完发现作者注释里明晃晃写着"这块写得有点乱凑合看" 瞬间人间真实 原来大佬也这么糊