检索工作台 · 四节完整方法
海角网github：把一次搜索做成有范围、有依据的记录
搜索这个组合词时，先决定自己要找仓库概况、文件内容，还是某段文字的历史位置。把搜索类型、表达式和记录范围一起保存，下一次才知道为什么结果改变。本页讲检索与整理方法，不认定任何同名仓库的官方身份。
01 · 先拆问题，再选搜索类型
把“海角网github”记为原始需求，再补一句具体问题：我要找项目介绍，还是确认某个文件是否提过这个词？前一种先选择 Repositories，后一种选择 Code。搜索框里文字相同，搜索类型不同，得到的对象也不同；别把仓库条目数与文件条目数放在一起比较。
仓库搜索可从“海角网 in:readme”开始，用于查 README 中的提及；若关注名称，改试“haijiao in:name”。这是两次不同范围的教学表达式，不表示拼音就是官方名称，也不保证出现结果。把每次修改的理由写在旁边，例如“检查英文拼写线索”，而不是只保留最后一次表达式。
已从页面确认完整仓库名后，才进入 Code 使用 repo:所有者/仓库名 缩小范围。这里的中文是需要替换的字段，不是可直接粘贴的真实项目地址。查正文中的词可加 content:海角网；查路径中的线索可加 path:docs。不要把仓库搜索的 in:readme 原样搬进代码搜索。
一个有效的第一轮结束条件，是能说清自己搜了什么对象、匹配什么位置、还没覆盖什么。不必同时加语言、时间、星标等限制。每轮只改一个条件，才容易区分是拼写造成变化，还是筛选范围造成变化。本文的流程是学习建议，具体语法依据下方 GitHub 官方文档。
- 原始问题 → 搜索类型 → 查询表达式 → 本轮目的
- 仓库条目与文件条目分开计数；示例查询不构成身份判断。
02 · 按范围缩小，不把限制条件堆满
面对结果过多，先明确真正需要的材料。如果只是确认一段说明，语言和星标往往没有帮助；先限定已确认的仓库，再限定文档路径，更贴近问题。Code 中 path:docs 匹配路径里含有 docs 的文件；content:海角网 要求词出现在文件正文，能减少只因文件名相似而出现的结果。
若已经知道文件名，直接在仓库内使用 Go to file 文件查找器通常更省步骤。查找器适合按名字定位，全文检索适合找不确定在哪个文件中的文字。前者找不到某些构建或依赖目录时，应查看工具的排除规则，不能马上认定文件不存在。
零结果时先检查搜索类型、完整仓库名、空格和拼写，再撤掉最近加入的条件；回到宽查询后，逐个恢复限制。把“无结果”写成“本次表达式在这个搜索范围未命中”，而不是“所有仓库都没有”。代码索引有覆盖边界，当前网页代码搜索以默认分支为范围，历史版本要回到对应文件或提交阅读。
例如你要找旧教程的一句话，当前 Code 未命中，但已知资料指向旧版本。此时继续堆搜索词帮助有限，应沿旧版本文件定位并记下观察范围。这个虚构场景说明的是方法选择：查询解决发现问题，版本页面解决定位问题；两者互相补充，不能用其中一个的空结果替代全部证据。
- 结果多：优先缩小对象和路径。
- 结果少：撤回一项条件，检查是否误选搜索类型。
- 查旧文字：回到已知版本，不把默认分支搜索当作全部历史。
语法依据：GitHub Docs · 代码搜索语法 · GitHub Docs · 查找文件 · GitHub Docs · 代码搜索范围
03 · 去重保留关系，复盘保留过程
整理结果时，用完整的“所有者/仓库名”作为项目记录键，再把命中文件、匹配位置和查询轮次放在下一级。同一个仓库在三轮搜索里出现，项目表只写一行，证据表可以保留三条。这样既不会虚增项目数量，也不会丢掉不同文件对问题的解释。
名称相同但所有者不同，先保持两行；确认 fork 关系后可放入同组，但仍保留各自链接和差异说明。仓库搜索的 fork:true 会把 fork 纳入匹配范围，fork:only 只看 fork；当前网页代码搜索使用 is:fork 或 NOT is:fork。使用前写明想扩大覆盖，还是减少派生副本，避免把不同搜索模式的语法混起来。
去重不只是删掉相似标题。两份文件可能来自共同上游，转述同一句话不能自动算作两条独立证据；同一仓库不同版本也可能结论相反，应按版本分开。建议在笔记中增加“关系”一栏，标记同一项目重复命中、派生仓库、单纯引用或关系未确认，不仅用颜色表示。
复盘表可以保留查询编号、表达式、搜索类型、查看范围、保留理由和下一步。结束前问自己：新增限制排除了什么？是否只看了靠前几条？哪些结论只是摘要推断？下一轮只针对仍未解决的问题继续，不以收藏数量作为完成标准。这个记录方法由本站整理，用来说明检索过程，不能证明某个项目的质量或归属。
- 项目去重键：完整所有者/仓库名。
- 证据记录键：仓库 + 文件路径 + 版本位置。
- 关系分组保留来源链，未知关系保持未确认。
语法依据：GitHub Docs · 搜索fork
04 · 用固定版本引用，把结论写完整
普通文件链接可能指向 main 等分支，之后打开时内容可能已经变化。需要说明“当时这一段写了什么”时，应使用对应提交的文件链接。GitHub 文件页按 y 可以把地址改为当前所见版本的永久链接，地址中的分支位置会由具体提交标识替代；复制后再核对文件路径和内容是否对应。
永久链接固定的是版本位置，不是对文件内容的背书，也不承诺目标永远公开可访问。记录时仍应写清仓库、文件、提交标识、查看日期和有关段落。如果只截一张图片，另一位读者可能无法确认上下文；若只给仓库首页，也可能要重新翻找才能理解你指哪一句。
一条好的检索结论可以分成四句：原问题是什么；在哪个文件版本观察到什么；这些内容支持什么有限判断；什么仍然不知道。例如虚构笔记：“本次查找词语的文档提及；某固定版本的说明文件包含该词；只能确认文本提及，尚未确认项目归属。”字段留空比猜一个作者或时间更准确。
分享之前把原文摘录与自己的解释分开，并保留足以判断语境的段落位置。再次检索时，在旧笔记后追加新的观察，不覆盖原版本结论。若内容变化，比较前后文件并解释哪一项判断需要修订。由此得到的是一份可回看的研究记录，而不是会随搜索排序变化的临时链接集合。
- 引用字段：仓库、路径、提交、查看日期、观察范围。
- 结论格式：问题 → 观察 → 有限判断 → 待确认项。
语法依据：GitHub Docs · 文件永久链接