在絕大多數(shù)在線應(yīng)用場景中，數(shù)據(jù)是存儲在關(guān)系型數(shù)據(jù)庫中的，當(dāng)然，有特殊要求的場景中，我們也會將其他持久化存儲（如 ElasticSearch、HBase、MongoDB 等）作為輔助存儲。但不可否認(rèn)的是，關(guān)系型數(shù)據(jù)庫憑借幾十年的發(fā)展、生態(tài)積累、眾多成功的案例，依然是互聯(lián)網(wǎng)企業(yè)的核心存儲。
作為一個 Java 開發(fā)者，幾乎天天與關(guān)系型數(shù)據(jù)庫打交道，在生產(chǎn)環(huán)境中常用的關(guān)系型數(shù)據(jù)庫產(chǎn)品有 SQL Server、MySQL、Oracle 等。在使用這些數(shù)據(jù)庫產(chǎn)品的時候，基本上是如下思路：
在寫 Java 代碼的過程中，使用的是面向?qū)ο蟮乃季S去實(shí)現(xiàn)業(yè)務(wù)邏輯；
在設(shè)計(jì)數(shù)據(jù)庫表的時候，考慮的是第一范式、第二范式和第三范式；
在操作數(shù)據(jù)庫記錄的時候，使用 SQL 語句以及集合思維去考慮表的連接、條件語句、子查詢等的編寫。
這個時候，就需要一座橋梁將 Java 類（或是其他數(shù)據(jù)結(jié)構(gòu)）與關(guān)系型數(shù)據(jù)庫中的表，以及 Java 對象與表中的數(shù)據(jù)映射起來，實(shí)現(xiàn) Java 程序與數(shù)據(jù)庫之間的交互。
JDBC（Java DataBase Connectivity）是 Java 程序與關(guān)系型數(shù)據(jù)庫交互的統(tǒng)一 API。實(shí)際上，JDBC 由兩部分 API 構(gòu)成：第一部分是面向 Java 開發(fā)者的 Java API，它是一個統(tǒng)一的、標(biāo)準(zhǔn)的 Java API，獨(dú)立于各個數(shù)據(jù)庫產(chǎn)品的接口規(guī)范；第二部分是面向數(shù)據(jù)庫驅(qū)動程序開發(fā)者的 API，它是由各個數(shù)據(jù)庫廠家提供的數(shù)據(jù)庫驅(qū)動，是第一部分接口規(guī)范的底層實(shí)現(xiàn)，用于連接具體的數(shù)據(jù)庫產(chǎn)品。
在實(shí)際開發(fā) Java 程序時，我們可以通過 JDBC 連接到數(shù)據(jù)庫，并完成各種各樣的數(shù)據(jù)庫操作，例如 CRUD 數(shù)據(jù)、執(zhí)行 DDL 語句。這里以 JDBC 編程中執(zhí)行一條 Select 查詢語句作為例子，說明 JDBC 操作的核心步驟，具體如下：
注冊數(shù)據(jù)庫驅(qū)動類，指定數(shù)據(jù)庫地址，其中包括 DB 的用戶名、密碼及其他連接信息；
調(diào)用 DriverManager.getConnection() 方法創(chuàng)建 Connection 連接到數(shù)據(jù)庫；
調(diào)用 Connection 的 createStatement() 或 prepareStatement() 方法，創(chuàng)建 Statement 對象，此時會指定 SQL（或是 SQL 語句模板 + SQL 參數(shù)）；
通過 Statement 對象執(zhí)行 SQL 語句，得到 ResultSet 對象，也就是查詢結(jié)果集；
遍歷 ResultSet，從結(jié)果集中讀取數(shù)據(jù)，并將每一行數(shù)據(jù)庫記錄轉(zhuǎn)換成一個 JavaBean 對象；
關(guān)閉 ResultSet 結(jié)果集、Statement 對象及數(shù)據(jù)庫 Connection，從而釋放這些對象占用的底層資源。
無論是執(zhí)行查詢操作，還是執(zhí)行其他 DML 操作，1、2、3、4、6 這些步驟都會重復(fù)出現(xiàn)。為了簡化重復(fù)邏輯，提高代碼的可維護(hù)性，可以將上述重復(fù)邏輯封裝到一個類似 DBUtils 的工具類中，在使用時只需要調(diào)用 DBUtils 工具類中的方法即可。當(dāng)然，我們也可以使用“反射+配置”的方式，將步驟 5 中關(guān)系模型到對象模型的轉(zhuǎn)換進(jìn)行封裝，但是這種封裝要做到通用化且兼顧靈活性，就需要一定的編程功底。
為了處理上述代碼重復(fù)的問題以及后續(xù)的維護(hù)問題，我們在實(shí)踐中會進(jìn)行一系列評估，選擇一款適合項(xiàng)目需求、符合人員能力的 ORM（Object Relational Mapping，對象-關(guān)系映射）框架來封裝 1~6 步的重復(fù)性代碼，實(shí)現(xiàn)對象模型、關(guān)系模型之間的轉(zhuǎn)換。這正是ORM 框架的核心功能：根據(jù)配置（配置文件或是注解）實(shí)現(xiàn)對象模型、關(guān)系模型兩者之間無感知的映射（如下圖）。
對象模型與關(guān)系模型的映射
在生產(chǎn)環(huán)境中，數(shù)據(jù)庫一般都是比較稀缺的，數(shù)據(jù)庫連接也是整個服務(wù)中比較珍貴的資源之一。建立數(shù)據(jù)庫連接涉及鑒權(quán)、握手等一系列網(wǎng)絡(luò)操作，是一個比較耗時的操作，所以我們不能像上述 JDBC 基本操作流程那樣直接釋放掉數(shù)據(jù)庫連接，否則持久層很容易成為整個系統(tǒng)的性能瓶頸。
Java 程序員一般會使用數(shù)據(jù)庫連接池的方式進(jìn)行優(yōu)化，此時就需要引入第三方的連接池實(shí)現(xiàn)，當(dāng)然，也可以自研一個連接池，但是要處理連接活躍數(shù)、控制連接的狀態(tài)等一系列操作還是有一定難度的。另外，有一些查詢返回的數(shù)據(jù)是需要本地緩存的，這樣可以提高整個程序的查詢性能，這就需要緩存的支持。
如果沒有 ORM 框架的存在，這就需要我們 Java 開發(fā)者熟悉相關(guān)連接池、緩存等組件的 API 并手動編寫一些“黏合”代碼來完成集成，而且這些代碼重復(fù)度很高，這顯然不是我們希望看到的結(jié)果。
很多 ORM 框架都支持集成第三方緩存、第三方數(shù)據(jù)源等常用組件，并對外提供統(tǒng)一的配置接入方式，這樣我們只需要使用簡單的配置即可完成第三方組件的集成。當(dāng)我們需要更換某個第三方組件的時候，只需要引入相關(guān)依賴并更新配置即可，這就大大提高了開發(fā)效率以及整個系統(tǒng)的可維護(hù)性。
下面我們就簡單介紹一下在實(shí)踐中常用的幾種 ORM 框架。
Hibernate
Hibernate 是 Java 生態(tài)中著名的 ORM 框架之一。Hibernate 現(xiàn)在也在擴(kuò)展自己的生態(tài)，開始支持多種異構(gòu)數(shù)據(jù)的持久化，不僅僅提供 ORM 框架，還提供了 Hibernate Search 來支持全文搜索，提供 validation 來進(jìn)行數(shù)據(jù)校驗(yàn)，提供 Hibernate OGM 來支持 NoSQL 解決方案。
這里我們要重點(diǎn)講解的是 Hibernate ORM 的相關(guān)內(nèi)容，截至 2020 年底，Hibernate ORM 的最新版本是 5.4 版本，6.0 版本還正在開發(fā)中。作為一個老牌的 ORM 框架，Hibernate 經(jīng)受住了 Java EE 企業(yè)級應(yīng)用的考驗(yàn)，一度成為 Java ORM 領(lǐng)域的首選框架。
在使用 Hibernate 的時候，Java 開發(fā)可以使用映射文件或是注解定義 Java 語言中的類與數(shù)據(jù)庫中的表之間的各種映射關(guān)系，這里使用到的映射文件后綴為“.hbm.xml”。hbm.xml 映射文件將一張數(shù)據(jù)庫表與一個 Java 類進(jìn)行關(guān)聯(lián)之后，該數(shù)據(jù)庫表中的每一行記錄都可以被轉(zhuǎn)換成對應(yīng)的一個 Java 對象。正是由于 Hibernate 映射的存在，Java 開發(fā)只需要使用面向?qū)ο笏季S就可以完成數(shù)據(jù)庫表的設(shè)計(jì)。
在 Java 這種純面向?qū)ο蟮恼Z言中，兩個 Java 對象之間可能存在一對一、一對多或多對多等復(fù)雜關(guān)聯(lián)關(guān)系。Hibernate 中的映射文件也必須要能夠表達(dá)這種復(fù)雜關(guān)聯(lián)關(guān)系才能夠滿足我們的需求，同時，還要能夠?qū)⑦@種關(guān)聯(lián)關(guān)系與數(shù)據(jù)庫中的關(guān)聯(lián)表、外鍵等一系列關(guān)系模型中的概念進(jìn)行映射，這也就是 ORM 框架中常提到的“關(guān)聯(lián)映射”。
下面我們就來結(jié)合示例介紹“一對多”關(guān)聯(lián)關(guān)系。例如，一個顧客（Customer）可以創(chuàng)建多個訂單（Order），而一個訂單（Order）只屬于一個顧客（Customer），兩者之間存在一對多的關(guān)系。在 Java 程序中，可以在 Customer 類中添加一個 List 類型的字段來維護(hù)這種一對多的關(guān)系；在數(shù)據(jù)庫中，可以在訂單表（t_order）中添加一個 customer_id 列作為外鍵，指向顧客表（t_customer）的主鍵 id，從而維護(hù)這種一對多的關(guān)系，如下圖所示：
關(guān)系模型中的一對多和對象模型中的一對多
在 Hibernate 中，可以通過如下 Customer.hbm.xml 配置文件將這兩種關(guān)系進(jìn)行映射：
<hibernate-mapping>
<!-- 這里指定了Customer類與t_customer表之間的映射 -->
<class name="com.mybatis.test.Customer" table="t_customer">
<!-- Customer類中的id屬性與t_customer表中主鍵id之間的映射 -->
<id name="id" column="id"/>
<!-- Customer類中的name屬性與t_customer表中name字段之間的映射 -->
<property name="name" column="name"/>
<!-- Customer指定了Order與Customer 一對多的映射關(guān)系 -->
<set name="orders" cascade="save,update,delete">
<key column="customer_id"/>
<one-to-many class="com.mybatis.test.Order"/>
</set>
</class>
</hibernate-mapping>
如果是雙向關(guān)聯(lián)，則在 Java 代碼中，可以直接在 Order 類中添加 Customer 類型的字段指向關(guān)聯(lián)的 Customer 對象，并在相應(yīng)的 Order.hbm.xml 配置文件中進(jìn)行如下配置：
復(fù)制代碼
一對一、多對多等關(guān)聯(lián)映射在 Hibernate 映射文件中，都定義了相應(yīng)的 XML 標(biāo)簽，原理與“一對多”基本一致，只是使用方式和場景略有不同，這里就不再展開介紹，你若感興趣的話可以參考 Hibernate 的官方文檔進(jìn)行學(xué)習(xí)。
除了能夠完成面向?qū)ο竽Ｐ团c數(shù)據(jù)庫中關(guān)系模型的映射，Hibernate 還可以幫助我們屏蔽不同數(shù)據(jù)庫產(chǎn)品中 SQL 語句的差異。
我們知道，雖然目前有 SQL 標(biāo)準(zhǔn)，但是不同的關(guān)系型數(shù)據(jù)庫產(chǎn)品對 SQL 標(biāo)準(zhǔn)的支持有細(xì)微不同，這就會出現(xiàn)一些非常尷尬的情況，例如，一條 SQL 語句在 MySQL 上可以正常執(zhí)行，而在 Oracle 數(shù)據(jù)庫上執(zhí)行會報(bào)錯。
Hibernate封裝了數(shù)據(jù)庫層面的全部操作，Java 程序員不再需要直接編寫 SQL 語句，只需要使用 Hibernate 提供的 API 即可完成數(shù)據(jù)庫操作。
例如，Hibernate 為用戶提供的 Criteria 是一套靈活的、可擴(kuò)展的數(shù)據(jù)操縱 API，最重要的是 Criteria 是一套面向?qū)ο蟮?API，使用它操作數(shù)據(jù)庫的時候，Java 開發(fā)者只需要關(guān)注 Criteria 這套 API 以及返回的 Java 對象，不需要考慮數(shù)據(jù)庫底層如何實(shí)現(xiàn)、SQL 語句如何編寫，等等。
下面是 Criteria API 的一個簡單示例：
復(fù)制代碼
list = criteria.add(Restrictions.like("name","yang%")).add(Restrictions.gt("id", 0)).list();
// 創(chuàng)建Criteria對象，用來查詢Customer對象Criteria criteria = session.createCriteria(Customer.class, "u");//查詢出id大于0，且名字中以yang開頭的顧客數(shù)據(jù)Listlist = criteria.add(Restrictions.like("name","yang%")).add(Restrictions.gt("id", 0)).list();
除了 Criteria API 之外，Hibernate 還提供了一套面向?qū)ο蟮牟樵冋Z言—— HQL（Hibernate Query Language）。從語句的結(jié)構(gòu)上來看，HQL 語句與 SQL 語句十分類似，但這二者也是有區(qū)別的：HQL 是面向?qū)ο蟮牟樵冋Z言，而 SQL 是面向關(guān)系型的查詢語言。
在實(shí)現(xiàn)復(fù)雜數(shù)據(jù)庫操作的時候，我們可以使用 HQL 這種面向?qū)ο蟮牟樵冋Z句來實(shí)現(xiàn)，Hibernate 的 HQL 引擎會根據(jù)底層使用的數(shù)據(jù)庫產(chǎn)品，將 HQL 語句轉(zhuǎn)換成合法的 SQL 語句。
Hibernate 通過其簡潔的 API 以及統(tǒng)一的 HQL 語句，幫助上層程序屏蔽掉底層數(shù)據(jù)庫的差異，增強(qiáng)了程序的可移植性。
另外，Hibernate 還具有如下的一些其他優(yōu)點(diǎn)：
Hibernate API 本身沒有侵入性，也就是說，業(yè)務(wù)邏輯感知不到 Hibernate 的存在，也不需要繼承任何 Hibernate 包中的接口；
Hibernate 默認(rèn)提供一級緩存、二級緩存（一級緩存默認(rèn)開啟，二級緩存需要配置開啟），這兩級緩存可以降低數(shù)據(jù)庫的查詢壓力，提高服務(wù)的性能；
Hibernate 提供了延遲加載的功能，可以避免無效查詢；
Hibernate 還提供了由對象模型自動生成數(shù)據(jù)庫表的逆向操作。
但需要注意的是，Hibernate 并不是一顆“銀彈”，我們無法在面向?qū)ο竽Ｐ椭姓业綌?shù)據(jù)庫中所有概念的映射，例如，索引、函數(shù)、存儲過程等。在享受 Hibernate 帶來便捷的同時，我們還需要忍受它的一些缺點(diǎn)。例如，索引對提升數(shù)據(jù)庫查詢性能有很大幫助，我們建立索引并適當(dāng)優(yōu)化 SQL 語句，就會讓數(shù)據(jù)庫使用合適的索引提高整個查詢的速度。但是，我們很難修改 Hibernate 生成的 SQL 語句。為什么這么說呢？因?yàn)樵谝恍﹫鼍爸?，?shù)據(jù)庫設(shè)計(jì)非常復(fù)雜，表與表之間的關(guān)系錯綜復(fù)雜，Hibernate 引擎生成的 SQL 語句會非常難以理解，要讓生成的 SQL 語句使用正確的索引更是難上加難，這就很容易生成慢查詢 SQL。
另外，在一些大數(shù)據(jù)量、高并發(fā)、低延遲的場景中，Hibernate 在性能方面帶來的損失就會逐漸顯現(xiàn)出來。
當(dāng)然，從其他角度來看 Hibernate，還會有一些其他的問題，這里就不再展開介紹，你若感興趣的話可以自行去查閱一些資料進(jìn)行深入了解。
Spring Data JPA
在開始介紹 Spring Data JPA 之前，我們先要來介紹一下 JPA（Java Persistence API）規(guī)范。
JPA 是在 JDK 5.0 后提出的 Java 持久化規(guī)范（JSR 338）。JPA 規(guī)范本身是為了整合市面上已有的 ORM 框架，結(jié)束 Hibernate、EclipseLink、JDO 等 ORM 框架各自為戰(zhàn)的割裂局面，簡化 Java 持久層開發(fā)。
JPA 規(guī)范從現(xiàn)有的 ORM 框架中借鑒了很多優(yōu)點(diǎn)，例如，Gavin King 作為 Hibernate 創(chuàng)始人，同時也參與了 JPA 規(guī)范的編寫，所以在 JPA 規(guī)范中可以看到很多與 Hibernate 類似的概念和設(shè)計(jì)。
既然 JPA 是一個持久化規(guī)范，沒有提供具體持久化實(shí)現(xiàn)，那誰來提供實(shí)現(xiàn)呢？答案是市面上的 ORM 框架，例如，Hibernate、EclipseLink 等都提供了符合 JPA 規(guī)范的具體實(shí)現(xiàn)，如下圖所示：
JPA 生態(tài)圖
JPA 有三個核心部分：ORM 映射元數(shù)據(jù)、操作實(shí)體對象 API 和面向?qū)ο蟮牟樵冋Z言（JPQL）。這與 Hibernate 的核心功能基本類似，就不再重復(fù)講述。
Java 開發(fā)者應(yīng)該都知道“Spring 全家桶”的強(qiáng)大，Spring 目前已經(jīng)成為事實(shí)上的標(biāo)準(zhǔn)了，很少有企業(yè)會完全離開 Spring 來開發(fā) Java 程序?，F(xiàn)在的 Spring 已經(jīng)不僅僅是最早的 IoC 容器了，而是整個 Spring 生態(tài)，例如，Spring Cloud、Spring Boot、Spring Security 等，其中就包含了 Spring Data。
Spring Data 是 Spring 在持久化方面做的一系列擴(kuò)展和整合，下圖就展示了 Spring Data 中的子項(xiàng)目：
Spring Data 生態(tài)圖
Spring Data 中的每個子項(xiàng)目都對應(yīng)一個持久化存儲，通過不斷的整合接入各種持久化存儲的能力，Spring 的生態(tài)又向前邁進(jìn)了一大步，其中最常被大家用到的應(yīng)該就是 Spring Data JPA。
Spring Data JPA 是符合 JPA 規(guī)范的一個 Repository 層的實(shí)現(xiàn)，其所在的位置如下圖所示：
Spring Data JPA 生態(tài)圖
雖然市面上的絕大多數(shù) ORM 框架都實(shí)現(xiàn)了 JPA 規(guī)范，但是它們在 JPA 基礎(chǔ)上也有各自的發(fā)展和修改，這樣導(dǎo)致我們在使用 JPA 的時候，依舊無法無縫切換底層的 ORM 框架實(shí)現(xiàn)。而使用 Spring Data JPA 時，由于Spring Data JPA 幫助我們抹平了各個 ORM 框架的差異，從而可以讓我們的上層業(yè)務(wù)無縫地切換 ORM 實(shí)現(xiàn)框架。
MyBatis
在這一講的最后，結(jié)合上述兩個 ORM 框架的知識點(diǎn)，我們再來介紹一下本課程的主角—— MyBatis。
Apache 基金會中的 iBatis 項(xiàng)目是 MyBatis 的前身。iBatis 項(xiàng)目由于各種原因，在 Apache 基金會并沒有得到很好的發(fā)展，最終于 2010 年脫離 Apache，并更名為 MyBatis。三年后，也就是 2013 年，MyBatis 將源代碼遷移到了 GitHub。
MyBatis 中一個重要的功能就是可以幫助 Java 開發(fā)封裝重復(fù)性的 JDBC 代碼，這與前文分析的 Spring Data JPA 、Hibernate 等 ORM 框架一樣。MyBatis 封裝重復(fù)性代碼的方式是通過 Mapper 映射配置文件以及相關(guān)注解，將 ResultSet 結(jié)果映射為 Java 對象，在具體的映射規(guī)則中可以嵌套其他映射規(guī)則和必要的子查詢，這樣就可以輕松實(shí)現(xiàn)復(fù)雜映射的邏輯，當(dāng)然，也能夠?qū)崿F(xiàn)一對一、一對多、多對多關(guān)系映射以及相應(yīng)的雙向關(guān)系映射。
很多人會將 Hibernate 和 MyBatis 做比較，認(rèn)為 Hibernate 是全自動 ORM 框架，而 MyBatis 只是半自動的 ORM 框架或是一個 SQL 模板引擎。其實(shí)，這些比較都無法完全說明一個框架比另一個框架先進(jìn)，關(guān)鍵還是看應(yīng)用場景。
MyBatis 相較于 Hibernate 和各類 JPA 實(shí)現(xiàn)框架更加靈活、更加輕量級、更加可控。
我們可以在 MyBatis 的 Mapper 映射文件中，直接編寫原生的 SQL 語句，應(yīng)用底層數(shù)據(jù)庫產(chǎn)品的方言，這就給了我們直接優(yōu)化 SQL 語句的機(jī)會；
我們還可以按照數(shù)據(jù)庫的使用規(guī)則，讓原生 SQL 語句選擇我們期望的索引，從而保證服務(wù)的性能，這就特別適合大數(shù)據(jù)量、高并發(fā)等需要將 SQL 優(yōu)化到極致的場景；
在編寫原生 SQL 語句時，我們也能夠更加方便地控制結(jié)果集中的列，而不是查詢所有列并映射對象后返回，這在列比較多的時候也能起到一定的優(yōu)化效果。（當(dāng)然，Hibernate 也能實(shí)現(xiàn)這種效果，需要在實(shí)體類添加對應(yīng)的構(gòu)造方法。）
在實(shí)際業(yè)務(wù)中，對同一數(shù)據(jù)集的查詢條件可能是動態(tài)變化的，如果你有使用 JDBC 或其他類似框架的經(jīng)歷應(yīng)該能體會到，拼接 SQL 語句字符串是一件非常麻煩的事情，尤其是條件復(fù)雜的場景中，拼接過程要特別小心，要確保在合適的位置添加“where”“and”“in”等 SQL 語句的關(guān)鍵字以及空格、逗號、等號等分隔符，而且這個拼接過程非?？菰?、沒有技術(shù)含量，可能經(jīng)過反復(fù)調(diào)試才能得到一個可執(zhí)行的 SQL 語句。
MyBatis 提供了強(qiáng)大的動態(tài) SQL 功能來幫助我們開發(fā)者擺脫這種重復(fù)勞動，我們只需要在映射配置文件中編寫好動態(tài) SQL 語句，MyBatis 就可以根據(jù)執(zhí)行時傳入的實(shí)際參數(shù)值拼湊出完整的、可執(zhí)行的 SQL 語句。
總結(jié)
在這一講，我們重點(diǎn)介紹了 3 種常見的 ORM 持久化框架，那在實(shí)際工作中我們又應(yīng)該如何選擇合適的持久層框架呢？
從性能角度來看，Hibernate、Spring Data JPA 在對 SQL 語句的掌控、SQL 手工調(diào)優(yōu)、多表連接查詢等方面，不及 MyBatis 直接使用原生 SQL 語句方便、高效；
從可移植性角度來看，Hibernate 幫助我們屏蔽了底層數(shù)據(jù)庫方言，Spring Data JPA 幫我們屏蔽了 ORM 的差異，而 MyBatis 因?yàn)橹苯泳帉懺?SQL，會與具體的數(shù)據(jù)庫完全綁定（但實(shí)踐中很少有項(xiàng)目會來回切換底層使用的數(shù)據(jù)庫產(chǎn)品或 ORM 框架，所以這點(diǎn)并不是特別重要）；
從開發(fā)效率角度來看，Hibernate、Spring Data JPA 處理中小型項(xiàng)目的效率會略高于 MyBatis（這主要還是看需求和開發(fā)者技術(shù)棧）。
除了這三方面之外，還有很多方面需要在技術(shù)選型中考慮進(jìn)去，例如，預(yù)估的 QPS、P99 等性能指標(biāo)，等等。在技術(shù)選型時，我們也要統(tǒng)籌考慮更多方面，才能選出最合適自己的方案。
那除了上面提到的三個方面，在技術(shù)選型中還要考慮哪些其他內(nèi)容呢？歡迎你在評論區(qū)留言，與我分享和交流。
在下一講，我會和你分享“MyBatis 入門的使用示例”，記得按時來聽課哦，我們下一講見！
《Java 工程師高薪訓(xùn)練營》
實(shí)戰(zhàn)訓(xùn)練+面試模擬+大廠內(nèi)推，想要提升技術(shù)能力，進(jìn)大廠拿高薪，點(diǎn)擊鏈接，提升自己！
