开发人员基本素养
这一篇放在全书开头，因为它决定你以后能走多远。框架可以换，API 可以查，但如果读不懂资料、找不到答案，又不愿意主动学习，学再多套视频课也很难摆脱照抄代码。
本书的判断很直接：英语阅读和 Google 检索这两项都很差，又不准备补上，基本就是在告别程序员这条职业道路，也很难再有像样的发展。 能跟着教程写出页面、完成眼前的重复工作，不等于具备独立解决问题和持续成长的能力。这两项基本功要从入门时就练，不能一直放在「以后再说」里。
这是作者对程序员学习与职业发展的判断。下面会给出理由和练法；不要求你入门前就精通英语，但要求你从现在开始补。
良好的英语阅读能力
Section titled “良好的英语阅读能力”英语阅读是基本功，不是加分项。 编程语言、Web 标准、框架文档、发布说明、报错和开源讨论，大量一手资料都以英文书写。遇到新版本、冷门问题和边界行为时，你需要直接读维护者怎么说，而不是等别人替你理解一遍。
本书不推荐把中文技术社区当主要信息来源。以 CSDN、博客园等站点的技术搜索结果为例，复制粘贴、过时教程、不解释原理的「亲测有效」太常见：同一个错误被十篇文章转载，很容易被误认为十个人验证过的结论。低质量资料不只是浪费时间，还会教给你错误的概念和习惯，越学越偏。 对还没有判断能力的初学者，这种副作用尤其大。
第三方翻译也有成本：可能落后版本、漏掉章节，或者把一个否定词、限制条件译错。没有中文资料就停下来，意味着你把自己的学习进度和解决问题的上限交给了别人。中文内容里有好作品，维护良好的官方中文文档也可以用，但它们不能成为不学英语、永远不碰原文的理由。
技术英语没有想象中难。先能读懂自己正在使用的 API、报错和示例，不需要先考过什么考试。我自己提升阅读能力的方法是：
- 查技术问题几乎只用 Google，优先英文关键词，直接读英文结果。 不认识的词就查，反复出现的术语很快会熟悉。
- 官方没有中文文档就直接读英文，不先花半天找第三方译本。 翻译工具可以辅助，但参数、否定词、版本要求和限制条件回到原文核对。
- 读正在使用的框架或库的源码、issue 和 PR。 从自己用过的 API 追起，同时熟悉命名、注释与讨论问题的方式。
坚持一段时间后，目标是能从一页英文资料里快速定位答案，而不是逐句翻译全文。每天拿一个真实问题练，比先背几个月单词再准备开始有效。
阅读之外，听懂英文课程、写清英文 issue、参与讨论，会继续扩大你能接触的资料、同行和工作机会。比如 freeCodeCamp 的课程就值得边学技术边练英语；外企、国际团队和远程岗位也不会替你消除沟通门槛。
主动学习及好奇心
Section titled “主动学习及好奇心”只学工作马上用到的东西，知识面很容易被当前公司的业务锁死。 平时要主动看技术资讯、优秀项目和开发者的文章。与工作相关、自己感兴趣的深入研究，暂时用不上的也可以粗浅了解；你不必提前知道每样知识将来能拿来做什么。
浏览网页时看到一个有趣的拖拽列表、一段滚动动画，或者用某个库时好奇它为什么这样设计，就找时间拆开看：读源码、搜实现、写一个最小例子。别把所有好奇心都压成「这个对我现在有什么用」。很多能力就是在这些看似用不上的探索中积累出来的。
同时，刷资讯不等于学习。每周至少挑一个问题亲手做，记下环境、输入、结果与解释；能复现、能说清，才是自己的收获。看见新框架就收藏，看完十篇「某技术已死」却没写一行代码，只会制造忙于学习的错觉。
使用搜索引擎的能力
Section titled “使用搜索引擎的能力”有人调侃写代码就是 Ctrl + C、Ctrl + V。连搜索都不会，连该去哪里找代码都不知道；而能找到、读懂并验证资料，才可能超出复制粘贴这一步。
搜索是一项需要练习的开发技能。 同一个问题，有人几分钟找到维护者的解释，有人翻几十篇转载仍然没有答案。差别往往在于：用什么搜索引擎、能不能拆出问题本质、选什么关键词，以及能不能读英文结果。
能访问 Google
Section titled “能访问 Google”本书明确推荐 Google 作为技术检索的默认搜索引擎，配合英文关键词使用。 查国际开源项目、英文报错、标准和技术讨论，我的经验是这套组合远比在百度里翻中文教程高效。它值得作为开发环境的一部分认真准备，而不是偶尔想起来才试试。
先确认自己能稳定访问 Google，并能打开搜索到的 GitHub、MDN、项目官网和技术讨论。打不开就把访问问题解决，别把「打不开」长期当成只看中文转载的理由。只打开 Google 首页、结果里的原始资料却全打不开，也不算准备好。
临时无法使用 Google 时，Bing可以应急，也可以直接查官网和项目 issue；备选入口用于继续排错，不该变成永远不补这项基本功的借口。
Google 也有广告、低质页面和错误答案。推荐它，是为了更高效地接近原始资料；最终读官方说明、看版本、做验证这几步仍要自己完成。
会用 Google
Section titled “会用 Google”会打开 Google，不等于会搜索。不要把整段业务描述扔进去，然后因为第一页没答案就宣布「搜不到」。下面用一个具体问题走一遍。
使用恰当的关键词
Section titled “使用恰当的关键词”假设你在做微信 H5 活动页，需要把 div 里的一段文字垂直居中。
- 先认清问题本质。 目前的问题是「文字在容器中垂直居中」，还没有出现微信特有的行为。它与营销活动无关，也不必限定
div：换成p或h1，布局方法通常一样。 - 去掉不影响答案的业务词。 不必搜「微信活动页 div 里面的文字怎么上下居中」，先提炼成「文字 垂直居中」。短而准确的词组，比堆一长串背景更容易调整。
- 加上真正有用的限定。 仅搜「文字 垂直居中」可能出现 Android、iOS 原生开发的结果。我们做的是网页布局，加上
CSS，得到CSS 文字 垂直居中；用英文就是CSS vertically center text。 - 有平台差异的证据，再补平台。 同一段代码在桌面正常、微信内置浏览器异常，这时才加
WeChat、iOS、具体版本等条件，而不是一开始把问题淹没在业务词里。
另一个常见场景是工具报错。先读完整错误，再搜索；别看到英文就跳过。 错误经常已经告诉你缺哪个包、哪个配置不合法，或者给了文档地址。
确实需要搜索时，保留错误名称、关键句、包名和必要的主版本。例如遇到 Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'vite'，可以从 ERR_MODULE_NOT_FOUND vite 开始；不要把自己的 /Users/姓名/项目/ 路径、整段调用栈、令牌和业务数据一起粘进去。若只有升级后出错，再加升级后的版本缩小范围。
搜索无果时，调整一个条件再试：去掉过窄的版本号、换成官方术语、用错误原文替代自己的描述，或者直接进入项目 issue。只把同一句话反复搜索十次，没有意义。
使用英文关键词
Section titled “使用英文关键词”查技术问题，默认先用英文，而不是中文实在搜不到才勉强试英文。 API 名、错误原文、项目名本来就是英文，沿用它们最容易找到官方文档和维护者的讨论。
不知道术语怎么说，可以先把「垂直居中」「请求取消」这样的短词组翻译为 vertical alignment、abort request，再加上 CSS、fetch 等技术限定。翻译工具用来帮你进入英文资料，不是帮你继续绕开它们。
我自己查技术问题几乎只用英文关键词，很多时候前几条结果就能找到有用线索。它不是保证每次都搜到的魔法，但长期效率值得尽早练出来。中文搜索的低质结果看得越多，并不会自动把英语这道门槛消掉。
使用高级搜索指令
Section titled “使用高级搜索指令”几个常用指令就够解决大量筛选问题：
| 写法 | 用途 | 示例 |
|---|---|---|
"词组" | 要求匹配该词组，适合保留错误中的关键句 | "Cannot find package" vite |
site: | 限定站点，也可进一步限定路径 | site:developer.mozilla.org fetch response.ok |
-词 / -site: | 排除关键词或指定站点，减少无关结果 | CSS vertically center text -site:csdn.net -site:cnblogs.com |
已知是 Vite 的问题，可以搜 site:github.com/vitejs/vite/issues "ERR_MODULE_NOT_FOUND"，直接找该项目的讨论。site: 后面不加空格；没有结果时先撤掉一部分限制，别把条件越加越多。
-fruit 排除的是匹配该词的结果，不代表搜索引擎理解并排除了整个「水果」主题。运算符也会调整，具体以 Google 搜索帮助为准。
找到结果之后
Section titled “找到结果之后”优先打开官方文档、维护者的 issue / PR、解释了原因且可复现的技术讨论。看发布时间、适用版本，以及讨论最终有没有解决；点赞数和搜索排名都不能替你完成这一步。
把方案放进最小例子里验证，再应用到项目。搜索摘要、AI 生成的概述和「亲测有效」只能提供线索，不能作为运行陌生命令、关闭安全校验或重写项目配置的充分理由。
关于百度等国产搜索引擎
Section titled “关于百度等国产搜索引擎”强烈建议避免用百度等国产搜索引擎查技术问题，尤其不要把百度设为开发时的默认搜索引擎。 本书不会把它们与 Google 并排写成「各有优势、按需选择」：按我长期查技术资料的体验，它们的低质结果和筛选成本已经足够构成放弃使用的理由。
这些问题，以百度最为典型：
- 推广自家内容，挤占真正有用的结果。 搜索本来是为了找到答案，却先被带去站内产品、聚合页和另一轮搜索。
- 广告和下载站干扰官网检索。 搜一个国外开发工具，官网没看到，先看到培训广告、套壳下载器和冒充官方的入口。初学者还没开始学，就先被误导。
- 搜索结果与问题不相干，或者直接给出错误方向。 问接口错误却被带去重装系统、关闭校验，照着做反而多出新问题。
- 内容农场与旧教程充斥结果。 一篇文章改个年份就成了「最新教程」，不交代版本，失效代码又被复制一轮。
- CSDN、博客园等站点的大量转载增加噪声。 复制粘贴、没有推导的「亲测有效」、只有提问没有答案的页面，看得越多越容易浪费时间，甚至形成错误理解。
对本书而言，这类批量复制、没有解释和验证的技术内容就是垃圾信息。中文技术搜索和这些传统社区的内容质量，差到不适合作为学习的默认入口，甚至会起副作用。 有好文章，不代表值得让初学者在垃圾堆里碰运气；同一段错误代码在五个网站出现，也不会因此变成正确答案。
具体做法很简单：默认 Google + 英文关键词，需要时用 -site:csdn.net -site:cnblogs.com 排除噪声；知道项目名称就直接查官网和 issue。某篇中文文章确实有原创分析、版本说明和可复现代码，可以读，但别把平台的搜索权重当成质量保证。
珍爱生命，远离百度。 把时间花在理解问题和写代码上，别耗在辨认广告、洗稿和错误答案上。
先主动思考、检索和尝试，再带着结果提问。 别人没有义务替你读错误信息、替你完成第一次搜索，或者猜一张截图背后的项目。你的时间宝贵，别人的也一样；一句「不行，求大佬」是在把自己的工作丢给别人。
提问时说明：
- 原本想解决什么问题。 给出目标、背景、实际结果和预期结果，别只询问自己猜测的方案。你想解决 A，选了方案 B，却卡在 C；只问 C 怎么办，别人可能陪你绕很远，其实 A 本来就有更简单的解法。
- 怎样复现。 提供最小代码、步骤、必要的环境版本和原始错误；代码发文本或可运行链接，不只发截图。
- 已经试过什么。 列出检索线索、方案、结果和自己的猜测，避免别人重复推荐你已经排除的路径。
刚入门不知道问题属于哪个术语，可以如实描述目标、操作与错误，再请人帮忙定位；做过尝试也要及时求助，不必先独自卡上几天来证明努力。关键是把自己已经知道的信息交代清楚。
共享代码和日志前移除凭据、个人资料和无关数据。推荐认真读一遍提问的智慧，准备示例时参考如何创建最小可复现示例。
良好的学习能力
Section titled “良好的学习能力”主动探索、检索和提问，最终都要落到自己理解并掌握知识。面对一项新技术，至少问清：
- 它是什么，解决哪类问题？
- 有什么优缺点，能做什么，不能做什么？
- 适用场景、兼容性、性能和维护成本怎样？
- 基本语法、API 和实现原理是什么？
- 与已有方案相比，为什么值得用，或者为什么不选？
- 能否用自己的话讲清楚，并做一个例子验证？
不必把每项技术都学到精通，但别把「看过」「收藏了」「让 AI 写出来了」算成学会。先做一个最小实验，跑过正常、失败和边界情况，再写下自己的解释。说不清楚就继续查、继续试；积累到需要它时能快速上手，才算这次学习有了结果。