你是小阿巴，剛?cè)肼毜暮蠖顺绦騿T。

這天，產(chǎn)品經(jīng)理給你安排任務(wù)：阿巴阿巴，咱們網(wǎng)站要加一個(gè)文章搜索功能。

你心想：簡單，直接寫一句 SQL 查詢數(shù)據(jù)庫就搞定了~

SELECT * FROM article WHERE title LIKE '%關(guān)鍵詞%'

結(jié)果上線沒幾天，就收到了大量用戶的投訴！

• 怎么什么搜索結(jié)果都沒有??？

• 搜索結(jié)果亂七八糟，我想找的那篇內(nèi)容竟然排在最后面？

• 搜索一次竟然要等好幾秒才出結(jié)果？什么破系統(tǒng)！

你汗流浹背了：明明 SQL 寫對(duì)了啊，難道是 MySQL 數(shù)據(jù)庫不行？

這時(shí)，號(hào)稱 "后端之狗" 的魚皮路過。他瞄了一眼你的代碼，嘲笑道：肯定要用 Elasticsearch 來做搜索功能?。?/p>

你一臉懵：Elasticsearch？那是啥？

第一階段：認(rèn)識(shí) Elasticsearch

魚皮：Elasticsearch 簡稱 ES，是一個(gè)專門為搜索而生的分布式數(shù)據(jù)庫，也叫 搜索引擎數(shù)據(jù)庫。

它能存儲(chǔ)和管理大量文本數(shù)據(jù)，提供快速、準(zhǔn)確、靈活的全文檢索功能。你剛才用 LIKE 查詢搞不定的那些問題，用 ES 都能輕松解決。

你撓了撓頭：真有這么神？

魚皮：當(dāng)然。打個(gè)比方，MySQL 就像圖書館的書架，書按照分類整整齊齊地?cái)[放著，你想找某本書得自己一排一排去翻；而 ES 就像圖書館的電子檢索系統(tǒng)，你輸入關(guān)鍵詞，它立刻就能告訴你書在哪兒，還會(huì)把最相關(guān)內(nèi)容的排在最前面。

像全文搜索、日志分析、數(shù)據(jù)統(tǒng)計(jì)這些需要搜索能力的場(chǎng)景，ES 都能輕松搞定。

你眼前一亮：聽起來有點(diǎn)兒夯啊，那我趕緊裝一個(gè)試試。

第二階段：實(shí)戰(zhàn)應(yīng)用 安裝 Elasticsearch

機(jī)智如你，直接打開 ES 官網(wǎng) 下載了安裝包：

并且成功安裝運(yùn)行：

你：安裝好之后，我怎么操作它呢？

魚皮：ES 本身提供了 RESTful API，默認(rèn)在 9200 端口提供服務(wù)，你可以用 curl 命令或者 Postman 等接口測(cè)試工具直接發(fā) HTTP 請(qǐng)求來操作它。

不過對(duì)新手來說，更推薦先安裝一個(gè)官方的可視化工具 Kibana。

有了它，你可以直觀地查看分析數(shù)據(jù)、對(duì)數(shù)據(jù)進(jìn)行操作。

只需要到官網(wǎng)下載安裝包并運(yùn)行，啟動(dòng)之后訪問本機(jī)的 5601 端口，就能打開 Kibana 的管理界面了。在開發(fā)工具控制臺(tái)里，你可以直接輸入查詢語句，能夠立刻看到結(jié)果，非常方便。

基本操作

下面我來帶你實(shí)操一波 ES 的基本操作。

1）首先是 創(chuàng)建索引。ES 的 索引（Index） 相當(dāng)于 MySQL 里的表，是存放數(shù)據(jù)的容器。

創(chuàng)建索引的時(shí)候，還要定義 Mapping（映射），類似 MySQL 的表結(jié)構(gòu)，用來規(guī)定每個(gè)字段的類型、是否需要分詞、使用什么分詞器等等。

在 Kibana 開發(fā)工具中輸入這段代碼：

PUT /article
{
  "mappings": {
    "properties": {
      "title": { "type": "text", "analyzer": "standard" },
      "content": { "type": "text" },
      "tags": { "type": "keyword" },
      "viewCount": { "type": "long" },
      "isPublished": { "type": "boolean" },
      "createTime": { "type": "date" }
    }
  }
}

這段代碼創(chuàng)建了一個(gè)叫 article 的索引。其中 text 類型表示需要分詞的文本字段，適合做全文檢索；keyword 類型不會(huì)分詞，適合存標(biāo)簽、狀態(tài)這種需要精確匹配的內(nèi)容。其他的類型就比較好理解了，long 存數(shù)字，boolean 存 true 或者 false，date 存日期。設(shè)計(jì)索引的時(shí)候要根據(jù)業(yè)務(wù)需求合理選擇字段類型。

2）然后是 插入文檔。文檔（Document） 相當(dāng)于 MySQL 里的一行數(shù)據(jù)。ES 的文檔是用 JSON 格式存儲(chǔ)的，不需要像 MySQL 那樣提前定義好所有字段，而是隨時(shí)可以加新字段，非常靈活。

POST /article/_doc/1
{
"title": "魚皮的 Elasticsearch 入門教程",
"content": "魚皮帶你學(xué)習(xí) ES",
"cover": "封面圖地址",
"tags": ["ES", "搜索"],
"viewCount": 1000,
"isPublished": true,
"createTime": "2025-01-30"
}

3）有了數(shù)據(jù)之后，就可以體驗(yàn) ES 最核心的能力 搜索文檔。比如在 article 索引中搜索標(biāo)題包含 "魚皮教程" 的文章：

GET /article/_search
{
  "query": {
    "match": { "title": "魚皮教程" }
  }
}

你執(zhí)行完這條查詢，驚喜地發(fā)現(xiàn)：搜 "魚皮教程" 居然能匹配到 "魚皮的 ES 入門教程" 這篇文章！

魚皮點(diǎn)點(diǎn)頭：雖然標(biāo)題里并沒有 "魚皮教程" 這 4 個(gè)連著的字，但因?yàn)?ES 會(huì)自動(dòng)分詞，把 "魚皮" 和 "教程" 拆開分別匹配，所以就搜到了。

你感嘆道：哇，這才是搜索該有的樣子啊！

查詢語法 DSL

魚皮：沒錯(cuò)，ES 的搜索能力非常靈活強(qiáng)大。剛才你寫的那些操作語句，其實(shí)用的就是 ES 的 DSL（Domain Specific Language 領(lǐng)域特定語言）。就像學(xué)數(shù)據(jù)庫要學(xué) SQL 一樣，學(xué) ES 就得學(xué) DSL。不管是創(chuàng)建索引、插入文檔，還是搜索查詢，都是用這套 JSON 格式的語法來描述的。

其中最常用的就是查詢語法，常見的查詢類型有這么幾種：

• match 是全文檢索，會(huì)對(duì)搜索詞分詞之后再匹配

• term 是精確匹配，不分詞，適合查 id、狀態(tài)這種

• bool 可以組合多個(gè)條件，用 must （必須滿足）、 should （最好滿足）、 must_not （必須不滿足）來靈活控制

• range 用來做范圍查詢，比如查某個(gè)時(shí)間段內(nèi)的數(shù)據(jù)。

你不需要背這些語法，用到的時(shí)候問 AI 或者查文檔就行，多寫幾次就熟了。

用代碼操作 ES

你皺了皺眉：感覺寫這些 JSON 格式的 DSL 還是有點(diǎn)麻煩啊，我用 Java 代碼操作 ES 的時(shí)候，總不會(huì)也要手動(dòng)拼這堆 JSON 吧？

魚皮：當(dāng)然不用！ES 官方提供了各種語言的客戶端。比如你用 Java 語言，對(duì)應(yīng)的是 Java API Client，支持鏈?zhǔn)秸{(diào)用和類型安全。

對(duì)于 Spring 項(xiàng)目來說，更推薦用 Spring Data Elasticsearch，它可以讓你像用 MyBatis-Plus 操作 MySQL 一樣操作 ES。只需要定義一個(gè)實(shí)體類，加上 @Document 注解指定要操作的索引，再寫個(gè) Repository 接口繼承依賴包內(nèi)置的 ES 操作接口。

@Document(indexName = "article")
public class Article {
    @Id
    private Long id;
    private String title;
    private String content;
}


 public interface ArticleRepository extends ElasticsearchRepository {
    // 根據(jù)標(biāo)題搜索
    List                                  findByTitle(String title);
}
               

框架會(huì)根據(jù)方法名自動(dòng)生成查詢邏輯，基本的增刪改查方法就自動(dòng)實(shí)現(xiàn)了。

// 使用示例
// 插入文檔
articleRepository.save(article);
// 根據(jù) id 查詢
articleRepository.findById(1L);
// 根據(jù)標(biāo)題搜索
articleRepository.findByTitle("魚皮");
// 刪除文檔
articleRepository.deleteById(1L);

你感嘆道：這才是人寫的代碼??！優(yōu)雅，真是優(yōu)雅~ 我這就給 Java 代碼整上 ES！

魚皮：要注意，ES 版本更新很快，你用的客戶端版本要跟安裝的 ES 服務(wù)保持一致，不然會(huì)出各種奇奇怪怪的 Bug。

第三階段：實(shí)用特性

學(xué)會(huì)了基本操作之后，你興沖沖地把 MySQL 數(shù)據(jù)庫里的文章數(shù)據(jù)全部導(dǎo)入到了 ES，然后把網(wǎng)站的搜索功能改成從 ES 查詢。上線后效果立竿見影，搜索又快又準(zhǔn)，用戶好評(píng)如潮。

你非常開心：阿巴，俺可真厲害！

魚皮：不錯(cuò)不錯(cuò)，你已經(jīng)掌握了 ES 的基本操作，算是學(xué)會(huì) 80% 了。不過 ES 還有很多值得學(xué)習(xí)的實(shí)用特性，進(jìn)一步優(yōu)化你的搜索功能。

倒排索引

魚皮：先來考考你，你知道為什么 ES 能搜得又快又準(zhǔn)么？

你撓撓頭：阿巴阿巴……

魚皮笑道：關(guān)鍵在于它使用了 倒排索引 來存儲(chǔ)數(shù)據(jù)，這是 ES 最核心的特性。

舉個(gè)例子，假設(shè)咱們要存 3 篇博客文檔，用 MySQL 數(shù)據(jù)庫的話，存儲(chǔ)結(jié)構(gòu)是這樣的：

文檔 id

文檔內(nèi)容

1

感謝關(guān)注魚皮

2

魚皮是一名程序員

3

感謝關(guān)注編程導(dǎo)航

這種結(jié)構(gòu)下，如果用戶搜 “魚皮程序員”，MySQL 會(huì)傻乎乎地把它當(dāng)成一整個(gè)詞去匹配，結(jié)果可能啥也搜不到。

而 ES 的做法不一樣。它會(huì)先把文檔內(nèi)容按照單詞進(jìn)行切分，這個(gè)過程叫 分詞。然后再構(gòu)建 單詞到文檔 id 的映射關(guān)系，也就是 倒排索引。

有了上述的倒排索引，當(dāng)用戶搜索 “魚皮程序員” 時(shí)，搜索引擎數(shù)據(jù)庫會(huì)先對(duì)搜索詞進(jìn)行分詞，得到 “魚皮” 和 “程序員”，然后根據(jù)這兩個(gè)詞匯就能找到文檔 id 1、2 了。不用再一行一行遍歷表內(nèi)所有的數(shù)據(jù)，實(shí)現(xiàn)了更靈活、快速的 模糊搜索 。

你兩眼放光：原來如此，牛啊牛啊！

但是 ES 怎么知道一句話該拆成哪些詞呢？

分詞器

魚皮：好問題，這就要靠 分詞器 了，它負(fù)責(zé)把一段文本拆成一個(gè)個(gè)詞。

ES 內(nèi)置了標(biāo)準(zhǔn)分詞器，它基于 Unicode 文本分割算法設(shè)計(jì)，會(huì)按空格和標(biāo)點(diǎn)符號(hào)等來切分文本。但這個(gè)規(guī)則只適合英文，對(duì)中文基本是一個(gè)字一個(gè)字地拆，效果很差。

所以如果你要做中文搜索，必須安裝 IK 分詞器。它是專門為中文設(shè)計(jì)的，能夠智能識(shí)別中文詞匯的邊界，把句子正確地拆分成有意義的詞語。

IK 提供了兩種分詞模式：

• ik_smart 是智能分詞，盡量把詞分得少一點(diǎn)，比如 "好學(xué)生" 就只會(huì)拆成 "好學(xué)生" 一個(gè)詞

• ik_max_word 是最大化分詞，能拆的都拆，"好學(xué)生" 會(huì)被拆成 "好學(xué)生"、"好學(xué)"、"學(xué)生" 三個(gè)詞。

一般建議索引的時(shí)候用 ik_max_word 盡可能多分詞，搜索的時(shí)候用 ik_smart 提高精確度。

此外，IK 還支持自定義詞典。比如你想讓 “程序員魚皮” 作為一個(gè)完整的詞不被拆開，加到詞典里就行了。

高亮顯示

你好奇道：既然 ES 能分詞，那能不能在搜索結(jié)果中把命中的關(guān)鍵詞標(biāo)紅啊？

魚皮：當(dāng)然可以，ES 支持 高亮顯示 功能。只需要在查詢里加個(gè) highlight 參數(shù)，指定要高亮的字段就行：

GET /article/_search
{
  "query": {
    "match": { "title": "魚皮教程" }
  },
  "highlight": {
    "fields": { "title": {} }
  }
}

返回結(jié)果里，命中的關(guān)鍵詞會(huì)自動(dòng)被 標(biāo)簽包起來，前端拿到之后加個(gè)顏色樣式就搞定了。

你兩眼放光：這也太方便了吧！

不過還有個(gè)問題，現(xiàn)在雖然能夠搜索到內(nèi)容了，但怎么把最相關(guān)的結(jié)果排到前面呢？

相關(guān)性評(píng)分

魚皮：好問題。ES 會(huì)給每個(gè)搜索結(jié)果計(jì)算一個(gè)分?jǐn)?shù)，放到 _score 字段中，分?jǐn)?shù)高的排在前面。

你好奇道：這個(gè)分?jǐn)?shù)是怎么算的呢？

魚皮：ES 默認(rèn)用的是 BM25 算法，主要考慮三個(gè)因素：

• 詞頻 ，關(guān)鍵詞在文檔里出現(xiàn)的次數(shù)越多，分?jǐn)?shù)越高。這很好理解，一篇文章里反復(fù)提到 "魚皮"，說明它很可能就是在講魚皮相關(guān)的內(nèi)容。

• 文檔長度 ，同樣出現(xiàn)一次關(guān)鍵詞，在短文檔里占的比例更大，所以短文檔的分?jǐn)?shù)會(huì)更高一點(diǎn)。

• 稀有度 ，如果一個(gè)詞在所有文檔里都很常見，比如 "的"、"是"，那它對(duì)搜索結(jié)果的區(qū)分度就不大。反過來，如果一個(gè)詞很少見，只在少數(shù)文檔里出現(xiàn)，那命中這個(gè)詞的文檔就更有價(jià)值，分?jǐn)?shù)也更高。

魚皮：除了搜索，ES 還有個(gè)很實(shí)用的功能叫 聚合分析，有點(diǎn)像 MySQL 的 GROUP BY 分組查詢。

比如你想統(tǒng)計(jì)每個(gè)標(biāo)簽下有多少篇文章，寫個(gè)聚合查詢就行：

GET /article/_search
{
  "size": 0,
  "aggs": {
    "tag_count": {
      "terms": { "field": "tags" }
    }
  }
}

除了分組統(tǒng)計(jì)數(shù)量，ES 的聚合還能做求和、求平均值、找最大最小值、甚至多層嵌套聚合，能夠滿足開發(fā)各類數(shù)據(jù)報(bào)表的需求。

第四階段：生產(chǎn)環(huán)境實(shí)踐

用了一段時(shí)間 ES 后，你開始有點(diǎn)兒飄了。

沒事兒就對(duì)著新來的實(shí)習(xí)生阿坤吹牛皮：ES 我閉著眼睛都能寫！什么分詞、高亮、聚合，我都玩得賊溜兒~

結(jié)果沒多久，老板黑著臉找到你：有用戶投訴，說明明改了自己文章的標(biāo)題，但是搜索出來還是舊的，怎么回事？

你排查后發(fā)現(xiàn)：原來是 ES 里的數(shù)據(jù)和 MySQL 數(shù)據(jù)庫里的不一樣！當(dāng)初俺只是把數(shù)據(jù)一次性導(dǎo)入 ES，后來文章在數(shù)據(jù)庫里更新了，但 ES 里還是舊數(shù)據(jù)。

你有些頭大：唉，ES 和 MySQL 是兩套獨(dú)立的系統(tǒng)，數(shù)據(jù)不會(huì)自動(dòng)同步啊，咋辦??？

這時(shí)，旁邊的阿坤突然雞叫起來：我來！

數(shù)據(jù)同步方案

阿坤一邊打籃球一邊說：MySQL 和 ES 的數(shù)據(jù)同步，一般有這么幾種方案。

1）定時(shí)任務(wù)

每隔幾分鐘掃一遍數(shù)據(jù)庫，把最近更新的數(shù)據(jù)同步到 ES。優(yōu)點(diǎn)是實(shí)現(xiàn)簡單，缺點(diǎn)是有一定延遲。適合數(shù)據(jù)更新不頻繁、對(duì)實(shí)時(shí)性要求不高的場(chǎng)景。

2）雙寫

每次把數(shù)據(jù)寫入 MySQL 的時(shí)候順便也寫一份到 ES。優(yōu)點(diǎn)是能做到實(shí)時(shí)同步，缺點(diǎn)是會(huì)影響寫入性能，而且如果 ES 寫失敗了還得處理數(shù)據(jù)不一致的問題。適合數(shù)據(jù)寫入量不大的場(chǎng)景。

3）用 Logstash

它是 ES 官方提供的數(shù)據(jù)收集工具，可以配置從 MySQL 定時(shí)拉取數(shù)據(jù)同步到 ES。優(yōu)點(diǎn)是不用寫代碼，全靠配置驅(qū)動(dòng)，缺點(diǎn)是需要額外部署組件，靈活性也有限。

4）用 Canal 監(jiān)聽數(shù)據(jù)庫

Canal 是阿里開源的一個(gè)工具，它會(huì)偽裝成 MySQL 的從庫，實(shí)時(shí)監(jiān)聽數(shù)據(jù)庫的變更日志。數(shù)據(jù)庫一有改動(dòng)，Canal 立刻就能感知到，然后同步到 ES。優(yōu)點(diǎn)是能做到實(shí)時(shí)同步，缺點(diǎn)是部署和運(yùn)維相對(duì)麻煩一點(diǎn)。

像咱們這個(gè)文章系統(tǒng)，更新又不頻繁，用戶也能接受幾分鐘的延遲，用定時(shí)任務(wù)就完全夠了。如果以后做電商那種對(duì)實(shí)時(shí)性要求高的系統(tǒng)，再考慮上 Canal。

集群部署

魚皮走過來拍了拍阿坤的肩膀：不錯(cuò)不錯(cuò)，我再考考你們，如果 ES 服務(wù)器掛了怎么辦？

你支支吾吾：重…… 重啟？

魚皮搖頭：用戶等得起嗎？

阿坤：生產(chǎn)環(huán)境肯定不能只部署一臺(tái) ES 啊，得搭建 集群。

ES 集群中有幾種角色的節(jié)點(diǎn)。主節(jié)點(diǎn) 負(fù)責(zé)管理集群的狀態(tài)，比如哪些節(jié)點(diǎn)在線、索引的元數(shù)據(jù)等等。數(shù)據(jù)節(jié)點(diǎn) 負(fù)責(zé)存儲(chǔ)實(shí)際的數(shù)據(jù)，處理讀寫請(qǐng)求。一般生產(chǎn)環(huán)境至少部署 3 個(gè)節(jié)點(diǎn)，保證高可用。

魚皮追問：那如果數(shù)據(jù)量特別大，一個(gè)節(jié)點(diǎn)存不下怎么辦？

你眼前一亮，終于等到自己會(huì)的問題了，搶答道：刪除數(shù)據(jù)！

阿坤用看流浪狗的眼神看了你一眼，回答道：這就要說到 分片 了。分片就是把一個(gè)索引的數(shù)據(jù)拆成多份，分別存到不同的節(jié)點(diǎn)上。這樣單個(gè)節(jié)點(diǎn)存不下的海量數(shù)據(jù)，也能通過多節(jié)點(diǎn)分擔(dān)。而且多個(gè)節(jié)點(diǎn)可以并行處理查詢請(qǐng)求，性能也更好。

你有些不服氣：那萬一某個(gè)節(jié)點(diǎn)掛了，上面的數(shù)據(jù)不就丟了？

阿坤：所以還需要 副本。副本就是分片的備份。每個(gè)分片可以配置若干個(gè)副本，存在其他節(jié)點(diǎn)上。萬一某個(gè)節(jié)點(diǎn)掛了，副本可以頂上，這樣數(shù)據(jù)就不會(huì)丟失，服務(wù)也不會(huì)中斷。

其他生產(chǎn)實(shí)踐

魚皮拍了拍阿坤的肩膀：小伙子年輕有為啊！

這些都是 ES 在生產(chǎn)環(huán)境必須考慮的問題，此外還要學(xué)習(xí)：

• 深度分頁問題：ES 默認(rèn)只允許查詢前 10000 條數(shù)據(jù)，再往后翻就會(huì)報(bào)錯(cuò)。這是為了保護(hù)集群性能。如果確實(shí)需要給用戶深度翻頁，推薦使用更高效的 search_after。如果需要導(dǎo)出全量數(shù)據(jù)，可以結(jié)合 Point-in-Time API 使用。

• 性能調(diào)優(yōu)技巧：合理設(shè)計(jì) Mapping，該用 keyword 的別用 text；查詢的時(shí)候多用 filter 少用 query，因?yàn)?filter 會(huì)緩存結(jié)果；還有控制返回字段的數(shù)量，別動(dòng)不動(dòng)就查全部字段。

• ELK 日志方案：ES 最經(jīng)典的應(yīng)用場(chǎng)景之一就是做日志系統(tǒng)。ELK 是三個(gè)組件的縮寫，E 是 Elasticsearch 負(fù)責(zé)存儲(chǔ)和搜索日志，L 是 Logstash 負(fù)責(zé)收集和處理日志，K 是 Kibana 負(fù)責(zé)可視化展示。大廠排查線上問題，基本都靠這一套。

你羞愧地抬不起頭：我以為自己已經(jīng)掌握了 ES，原來只是學(xué)了個(gè)皮毛……

魚皮：小阿巴，你還要好好跟阿坤學(xué)習(xí)啊。

第五階段：深入原理

被連環(huán)拷問后，你主動(dòng)找到阿坤：坤哥，我想深入學(xué)習(xí) ES 的底層原理，你是怎么學(xué)的？

阿坤有些驚訝：咦？你不背八股文的么？去 面試刷題網(wǎng)站 - 面試鴨 刷刷題就好了呀！

你震驚了：現(xiàn)在的實(shí)習(xí)生，竟然恐怖如斯！

魚皮笑了笑：阿坤你別逗他了。其實(shí)可以帶著問題去學(xué)習(xí)，比如 ES 為什么這么快？

你搶答道：因?yàn)榈古潘饕?/p>

魚皮：沒錯(cuò)，但這只是一方面。ES 底層是基于 Lucene 搜索引擎庫的，它的倒排索引結(jié)構(gòu)經(jīng)過了高度優(yōu)化。另外 ES 會(huì)把常用的數(shù)據(jù)緩存在內(nèi)存里，查詢時(shí)優(yōu)先從內(nèi)存讀取，速度自然快。再加上 ES 是分布式的，可以把數(shù)據(jù)分片存儲(chǔ)到多個(gè)節(jié)點(diǎn)，并行處理查詢請(qǐng)求，幾方面加起來，性能就上去了。

再比如數(shù)據(jù)是怎么寫入的、查詢請(qǐng)求是怎么執(zhí)行的？

從這些問題出發(fā)，去閱讀相關(guān)的文章，或者像阿坤說的刷一刷 ES 高頻面試題，就能快速學(xué)會(huì)很多核心知識(shí)點(diǎn)。

如果想系統(tǒng)學(xué)習(xí)，推薦看 ES 官方文檔，因?yàn)?ES 的更新太快了，很多書籍可能已經(jīng)跟不上節(jié)奏了。

結(jié)尾

若干年后，你已經(jīng)成為了公司的 ES 搜索專家。不僅能熟練使用 ES 解決各種搜索問題，搭個(gè)集群架構(gòu)也是手拿把掐的。

你也像魚皮當(dāng)時(shí)一樣，耐心地給新人分享學(xué)習(xí) ES 的經(jīng)驗(yàn)，讓他們謹(jǐn)記一句話：ES 是實(shí)戰(zhàn)型技術(shù)，一定要多動(dòng)手實(shí)踐！

再次遇到魚皮是在一條昏暗的小巷，此時(shí)的他年過 35，灰頭土臉。你什么都沒說，只是給他點(diǎn)了個(gè)贊，投了 2 個(gè)幣。

不打擾，是你的溫柔~

一些對(duì)大家有用的資源：
100+ 編程學(xué)習(xí)路線 / 實(shí)戰(zhàn)項(xiàng)目 / 求職指導(dǎo)
100+ 簡歷模板
300+ 企業(yè)面試題庫 mianshiya.com
500+ AI 資源大全
1 對(duì) 1 模擬面試
動(dòng)畫學(xué)算法教程