1. 項目概述為什么MyBatis-Plus是后端開發(fā)的“瑞士軍刀”如果你是一名Java后端開發(fā)者尤其是和Spring Boot打交道的那么“MyBatis-Plus”這個名字你一定不陌生。它早已不是那個需要猶豫“要不要用”的選項而是成為了許多項目腳手架里默認(rèn)集成的標(biāo)配。但你真的用透它了嗎還是僅僅停留在“自動生成CRUD代碼”的層面今天我們不聊那些官網(wǎng)文檔里隨手就能查到的入門配置而是從一個有多年實戰(zhàn)經(jīng)驗的開發(fā)者視角深度拆解MyBatis-Plus后文簡稱MP那些真正提升開發(fā)效率、保障代碼質(zhì)量的核心特性、設(shè)計思想以及那些官方文檔里不會明說的“坑”和最佳實踐。簡單來說MP是MyBatis的一個強大增強工具在保留MyBatis所有靈活性的基礎(chǔ)上提供了大量開箱即用的功能。它的核心價值在于將開發(fā)者從大量重復(fù)、模板化的數(shù)據(jù)庫操作代碼中解放出來讓你能更專注于業(yè)務(wù)邏輯本身。從基礎(chǔ)的通用Mapper、分頁插件到更高級的字段自動填充、邏輯刪除、多租戶隔離再到性能優(yōu)化層面的二級緩存、SQL注入防護(hù)MP提供了一套近乎完整的ORM增強解決方案。理解并善用這些特性能讓你的開發(fā)速度提升一個量級同時讓代碼更加優(yōu)雅和健壯。2. 核心架構(gòu)與設(shè)計思想拆解2.1 不是替代而是增強MP與MyBatis的共生關(guān)系首先要明確一個關(guān)鍵點MP不是另一個ORM框架它不替代MyBatis。它的所有功能都是通過MyBatis的插件機(jī)制Interceptor和擴(kuò)展點來實現(xiàn)的。這意味著你可以在項目中同時使用原生的MyBatis寫復(fù)雜SQL又享受MP帶來的便捷。這種設(shè)計哲學(xué)非常聰明——它沒有重新發(fā)明輪子而是在現(xiàn)有強大輪子MyBatis的基礎(chǔ)上加裝了“自動駕駛”、“自動泊車”等高級功能。這種“增強”模式帶來了幾個巨大優(yōu)勢。第一學(xué)習(xí)成本極低。如果你熟悉MyBatis那么MP幾乎是無縫接入你原有的XML映射文件和Select等注解完全兼容。第二風(fēng)險可控。當(dāng)你遇到MP無法滿足的超復(fù)雜場景時你可以隨時退回到最原始、最強大的MyBatis模式去編寫SQL沒有任何束縛。第三生態(tài)兼容。所有MyBatis的第三方插件如分頁插件PageHelper在MP中有自己的實現(xiàn)和監(jiān)控工具都能繼續(xù)使用。2.2 核心接口與類理解MP的運作基石要玩轉(zhuǎn)MP必須理解其幾個核心接口和類它們是整個框架的骨架。BaseMapperT這是MP的基石也是一個“萬能”的Mapper接口。你只需要讓自己的Mapper接口繼承它并指定泛型T為你的實體類就立刻擁有了近20個通用的CRUD方法如selectByIdinsertupdateByIddeleteByIdselectListselectPage等。它的實現(xiàn)是由MP在運行時動態(tài)生成的你無需編寫任何SQL。IServiceT與ServiceImplM, T這是MP在Mapper層之上封裝的服務(wù)層抽象。IService定義了更豐富的業(yè)務(wù)常用方法如鏈?zhǔn)讲樵?、批量操作等。通常我們會?chuàng)建一個Service接口繼承IService并創(chuàng)建一個實現(xiàn)類繼承ServiceImpl同時將對應(yīng)的Mapper注入。這樣在Service層也能以非常簡潔的方式操作數(shù)據(jù)庫進(jìn)一步減少樣板代碼。QueryWrapperT和LambdaQueryWrapperT動態(tài)查詢構(gòu)造器是MP的靈魂之一。它們用于以Java代碼的方式動態(tài)構(gòu)建查詢條件避免在代碼中拼接SQL字符串從而有效防止SQL注入。LambdaQueryWrapper利用Lambda表達(dá)式通過方法引用來獲取實體字段名實現(xiàn)了編譯期檢查是更推薦的使用方式。UpdateWrapperT與QueryWrapper類似用于動態(tài)構(gòu)建更新條件。理解這些組件之間的關(guān)系是靈活運用MP的前提。它們共同構(gòu)成了從數(shù)據(jù)實體到數(shù)據(jù)庫操作的一條清晰、高效的鏈路。3. 核心特性深度解析與實戰(zhàn)要點3.1 通用CRUD不僅僅是節(jié)省代碼使用BaseMapper一行SQL不寫就能完成單表操作這確實是MP最吸引人的特性。但它的價值遠(yuǎn)不止于此。自動注入與ID生成策略當(dāng)你調(diào)用insert(entity)時MP會檢查實體類中標(biāo)記了TableId注解的字段。如果其生成策略設(shè)置為IdType.ASSIGN_ID默認(rèn)基于雪花算法或IdType.AUTO數(shù)據(jù)庫自增MP會在插入前自動生成ID并填充到實體對象中。這意味著你插入后實體對象是攜帶完整ID的可以直接用于后續(xù)邏輯無需再次查詢。字段自動填充這是提升開發(fā)體驗的利器。通過實現(xiàn)MetaObjectHandler接口你可以定義在插入或更新時自動為某些字段賦值。最常見的場景是create_timecreate_byupdate_timeupdate_by。Component public class MyMetaObjectHandler implements MetaObjectHandler { Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, createTime, LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, createBy, String.class, getCurrentUserId()); } Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); this.strictUpdateFill(metaObject, updateBy, String.class, getCurrentUserId()); } }注意字段自動填充依賴于MP的插件機(jī)制它發(fā)生在MP的insert或update方法被調(diào)用時。如果你直接使用原生MyBatis的Insert注解或XML執(zhí)行SQL自動填充是不會生效的。3.2 條件構(gòu)造器告別字符串拼接擁抱類型安全動態(tài)查詢是業(yè)務(wù)開發(fā)中的常態(tài)。傳統(tǒng)的做法是在Service層拼接WHERE子句的字符串極易出錯且存在SQL注入風(fēng)險。MP的條件構(gòu)造器完美解決了這個問題。QueryWrapper基礎(chǔ)用法QueryWrapperUser wrapper new QueryWrapper(); wrapper.eq(status, 1) .like(name, 張) .between(age, 18, 30) .orderByDesc(create_time); ListUser list userMapper.selectList(wrapper);LambdaQueryWrapper進(jìn)階用法推薦LambdaQueryWrapperUser lambdaWrapper new LambdaQueryWrapper(); lambdaWrapper.eq(User::getStatus, 1) .like(User::getName, 張) .between(User::getAge, 18, 30) .orderByDesc(User::getCreateTime); ListUser list userMapper.selectList(lambdaWrapper);使用LambdaQueryWrapper所有字段引用都是通過實體類的getter方法引用完成的。這樣做有兩個巨大好處第一類型安全編譯器會檢查字段是否存在方法引用是否正確第二重構(gòu)友好如果你用IDE重命名了實體類的字段或getter方法這里的引用會自動更新而字符串name則不會。復(fù)雜條件與子查詢 MP也支持復(fù)雜的AND/OR嵌套和子查詢。lambdaWrapper.and(w - w.eq(User::getType, A).or().eq(User::getType, B)) .inSql(User::getDeptId, select id from dept where parent_id 1);3.3 分頁插件優(yōu)雅處理海量數(shù)據(jù)分頁查詢是Web應(yīng)用的高頻需求。MP的分頁插件PaginationInnerInterceptor配置簡單功能強大。配置與啟用Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); // 添加分頁插件 interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }使用方式// 構(gòu)造分頁參數(shù)查詢第2頁每頁10條 PageUser page new Page(2, 10); // 構(gòu)造查詢條件可選 LambdaQueryWrapperUser wrapper new LambdaQueryWrapper(); wrapper.eq(User::getActive, true); // 執(zhí)行分頁查詢 PageUser resultPage userMapper.selectPage(page, wrapper); // 從 resultPage 中獲取數(shù)據(jù) ListUser records resultPage.getRecords(); // 當(dāng)前頁數(shù)據(jù)列表 long total resultPage.getTotal(); // 總記錄數(shù) long pages resultPage.getPages(); // 總頁數(shù)Page對象既是一個參數(shù)載體也是一個結(jié)果載體。執(zhí)行查詢后分頁數(shù)據(jù)當(dāng)前頁列表、總數(shù)等會自動填充回這個對象。實操心得對于超大數(shù)據(jù)量的分頁比如limit 1000000, 10使用selectPage性能會很差因為數(shù)據(jù)庫需要先掃描并跳過前100萬條記錄。對于這種“深度分頁”場景更優(yōu)的方案是使用“游標(biāo)分頁”或“基于上一次查詢最大ID的分頁”MP的條件構(gòu)造器可以很好地配合這種方案但插件本身不直接解決此性能問題。3.4 邏輯刪除數(shù)據(jù)無價刪除需謹(jǐn)慎物理刪除數(shù)據(jù)風(fēng)險極高。邏輯刪除是一種將“刪除”操作轉(zhuǎn)化為“更新”操作的方案將記錄標(biāo)記為已刪除狀態(tài)而非真正從磁盤移除。MP對此提供了近乎零配置的支持。啟用邏輯刪除在數(shù)據(jù)庫表中增加一個字段如deleted通常為tinyint或int類型默認(rèn)值為0。在實體類對應(yīng)字段上添加TableLogic注解。TableLogic private Integer deleted; // 0-未刪除 1-已刪除在application.yml中配置邏輯刪除的全局值可選新版MP可通過注解屬性配置。mybatis-plus: global-config: db-config: logic-delete-field: deleted # 全局邏輯刪除的實體字段名 logic-delete-value: 1 # 邏輯已刪除值 logic-not-delete-value: 0 # 邏輯未刪除值配置完成后當(dāng)你調(diào)用mapper.deleteById(1)時MP實際執(zhí)行的是UPDATE user SET deleted 1 WHERE id 1 AND deleted 0。而所有的select*方法MP都會自動在WHERE條件后追加AND deleted 0。這確保了被邏輯刪除的數(shù)據(jù)永遠(yuǎn)不會被業(yè)務(wù)查詢出來。注意事項聯(lián)表查詢邏輯刪除的自動過濾僅對當(dāng)前實體BaseMapper方法生效。如果你自己寫XML做多表關(guān)聯(lián)查詢MP無法自動為其他表追加deleted條件需要你在SQL中手動處理。唯一索引沖突如果表上對name字段有唯一索引邏輯刪除一條name‘張三’的記錄后就無法再插入一條name‘張三’的新記錄了因為索引約束的是整個表。此時需要考慮使用復(fù)合唯一索引將deleted字段也包含進(jìn)去或者使用delete_time代替deleted標(biāo)志。3.5 多租戶數(shù)據(jù)隔離與動態(tài)取消在多租戶SaaS系統(tǒng)中數(shù)據(jù)隔離是核心需求。MP通過TenantLineInnerInterceptor插件可以輕松實現(xiàn)基于tenant_id的自動過濾?；A(chǔ)配置Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); // 添加多租戶插件 TenantLineInnerInterceptor tenantInterceptor new TenantLineInnerInterceptor(); tenantInterceptor.setTenantLineHandler(new TenantLineHandler() { Override public Expression getTenantId() { // 從當(dāng)前請求上下文中獲取租戶ID例如從ThreadLocal或SecurityContext中獲取 String tenantId TenantContext.getCurrentTenantId(); return new StringValue(tenantId); } Override public String getTenantIdColumn() { return “tenant_id”; // 數(shù)據(jù)庫中的租戶ID列名 } Override public boolean ignoreTable(String tableName) { // 返回true表示某些表不需要租戶隔離如全局配置表 return “sys_config”.equalsIgnoreCase(tableName); } }); interceptor.addInnerInterceptor(tenantInterceptor); return interceptor; }配置后所有通過MP的BaseMapper執(zhí)行的增刪改查操作都會自動帶上AND tenant_id ‘xxx’條件。動態(tài)取消租戶隔離這是網(wǎng)絡(luò)熱詞中提到的一個高級場景。在某些后臺管理或數(shù)據(jù)統(tǒng)計功能中管理員可能需要跨租戶查詢數(shù)據(jù)。MP提供了兩種方式在Mapper方法上使用InterceptorIgnore(tenantLine “true”)注解。這可以標(biāo)注在自定義的Mapper方法上使其忽略多租戶插件。使用TenantLineHandler的ignoreTable方法。如上例直接配置某些表完全忽略。編程式動態(tài)忽略更靈活可以通過TenantContext臨時清空租戶ID或者使用MP的SqlSession執(zhí)行原生SQL。但更優(yōu)雅的方式是利用MP的StatementHandler在特定線程上下文中設(shè)置一個標(biāo)志讓TenantLineHandler的getTenantId方法根據(jù)這個標(biāo)志返回null從而實現(xiàn)當(dāng)前線程的本次操作忽略租戶過濾。踩坑記錄多租戶插件和分頁插件一起使用時要注意添加順序。通常建議先添加多租戶插件再添加分頁插件以確保分頁查詢的總數(shù)統(tǒng)計COUNT語句也正確地加上了租戶條件。4. 高級特性與性能優(yōu)化實戰(zhàn)4.1 字段加解密透明化處理敏感數(shù)據(jù)對于手機(jī)號、身份證號等敏感信息入庫前加密、出庫后解密是一個常見需求。MP沒有內(nèi)置加解密組件但可以通過實現(xiàn)TypeHandler或使用插件攔截Executor來優(yōu)雅實現(xiàn)。使用自定義TypeHandler實現(xiàn)字段級加密編寫一個加解密的TypeHandler。public class EncryptTypeHandler extends BaseTypeHandlerString { private final Encryptor encryptor new AESEncryptor(); // 你的加密工具類 Override public void setNonNullParameter(PreparedStatement ps, int i, String parameter, JdbcType jdbcType) throws SQLException { // 入庫時加密 ps.setString(i, encryptor.encrypt(parameter)); } Override public String getNullableResult(ResultSet rs, String columnName) throws SQLException { // 出庫時解密 String encrypted rs.getString(columnName); return encrypted ! null ? encryptor.decrypt(encrypted) : null; } // ... 其他重載方法 }在實體類的字段上通過TableField注解指定該TypeHandler。TableField(typeHandler EncryptTypeHandler.class) private String phoneNumber;這種方式對業(yè)務(wù)代碼完全透明service層拿到的entity對象中的phoneNumber字段已經(jīng)是解密后的明文而存入數(shù)據(jù)庫的則是密文。局限性TypeHandler的加解密發(fā)生在數(shù)據(jù)庫驅(qū)動層面它無法參與MP條件構(gòu)造器QueryWrapper的查詢。例如如果你用wrapper.eq(“phone_number”, “13800138000”)MP生成的SQL會是WHERE phone_number ‘13800138000’而數(shù)據(jù)庫里存的是密文這將導(dǎo)致查詢不到數(shù)據(jù)。對于需要根據(jù)加密字段查詢的場景需要額外處理比如在查詢前手動加密參數(shù)或者使用數(shù)據(jù)庫函數(shù)如MySQL的AES_ENCRYPT在SQL層處理但這會破壞透明性。4.2 代碼生成器快速啟動項目的利器MP的代碼生成器AutoGenerator可以一鍵生成EntityMapperXMLServiceController等全套代碼極大提升項目初始搭建速度。核心配置示例FastAutoGenerator.create(“jdbc:mysql://localhost:3306/test”, “root”, “password”) .globalConfig(builder - builder .author(“yourname”) // 作者 .outputDir(“D://code”) // 輸出目錄 .disableOpenDir() // 生成后不打開目錄 ) .packageConfig(builder - builder .parent(“com.example”) // 父包名 .moduleName(“demo”) // 模塊名 .entity(“entity”) // 實體包名 .mapper(“mapper”) .service(“service”) .controller(“controller”) ) .strategyConfig(builder - builder .addInclude(“user”, “order”) // 要生成的表 .entityBuilder() .enableLombok() // 啟用Lombok .enableTableFieldAnnotation() // 字段上添加TableField注解 .controllerBuilder() .enableRestStyle() // 生成RestController ) .templateEngine(new FreemarkerTemplateEngine()) // 使用Freemarker引擎 .execute();個人建議代碼生成器非常適合在項目初期搭建骨架或者為遺留數(shù)據(jù)庫快速生成基礎(chǔ)CRUD代碼。但對于長期維護(hù)的項目不建議過度依賴。特別是Controller層業(yè)務(wù)邏輯千變?nèi)f化生成的模板代碼往往需要大量修改。我通常只用它生成EntityMapper接口和空的XML文件Service層和Controller層根據(jù)業(yè)務(wù)需求手動編寫可控性更強。4.3 性能監(jiān)控與SQL分析MP內(nèi)置了PerformanceInterceptor舊版或通過Interceptor注解配置的SqlLogInterceptor可以輸出SQL語句及其執(zhí)行時間這對開發(fā)階段調(diào)試非常有用。配置SQL輸出mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 控制臺打印SQL更推薦使用p6spy這類第三方組件它可以輸出格式化更好、帶執(zhí)行時間的SQL并且能攔截到真正發(fā)送給JDBC驅(qū)動的語句。關(guān)鍵性能考量N1查詢問題這和MP本身關(guān)系不大更多是ORM使用不當(dāng)?shù)耐ú　．?dāng)你查詢一個用戶列表然后遍歷列表去查詢每個用戶的訂單時就會產(chǎn)生N1次查詢。解決方法是使用QueryWrapper的select方法只查詢需要的字段或者自己編寫聯(lián)表查詢的XML。大字段查詢使用QueryWrapper的select方法避免查詢textblob等大字段除非確實需要。批量操作MP的Service層提供了saveBatch和updateBatchById方法。但需要注意這些方法的默認(rèn)實現(xiàn)可能是一條條執(zhí)行SQL并非真正的批量提交。要啟用真正的批量執(zhí)行需要在數(shù)據(jù)庫連接URL后加上rewriteBatchedStatementstrueMySQL并且配置MyBatis的ExecutorType。5. 常見問題排查與避坑指南在實際開發(fā)中我們會遇到各種各樣的問題。下面是一些高頻問題的排查思路和解決方案。5.1 查詢結(jié)果與預(yù)期不符現(xiàn)象明明用wrapper.eq(“status”, 1)卻查出了所有數(shù)據(jù)。排查檢查SQL日志看生成的SQL語句是否正確。很可能條件沒有被拼接到SQL中。檢查字段名是否正確。數(shù)據(jù)庫是snake_caseuser_name而實體類是camelCaseuserName。MP默認(rèn)開啟了駝峰下劃線轉(zhuǎn)換但如果你在TableField中指定了value或者全局關(guān)閉了轉(zhuǎn)換就可能出現(xiàn)字段名映射錯誤。檢查是否有其他插件如多租戶、邏輯刪除添加了額外的條件影響了最終結(jié)果。5.2 更新操作失效或更新了全部數(shù)據(jù)現(xiàn)象調(diào)用updateById但數(shù)據(jù)沒變或者調(diào)用update(entity, wrapper)卻更新了整張表。排查updateById失效首先確認(rèn)傳入的實體對象id字段不為空且數(shù)據(jù)庫中存在該ID。查看SQL日志確認(rèn)UPDATE語句的WHERE條件是否包含id ?。誤更新全表這是使用UpdateWrapper時極易出現(xiàn)的嚴(yán)重BUG。永遠(yuǎn)不要使用update(null, wrapper)。正確的做法是// 錯誤如果entity為nullwrapper又沒有eq條件會更新全表 // update(null, wrapper); // 正確做法1使用UpdateWrapper的set方法 new UpdateWrapperUser().eq(“status”, 0).set(“status”, 1); // 正確做法2傳入一個空的Entity僅用于攜帶Version樂觀鎖字段等但Wrapper必須帶條件 update(new User(), wrapper);最安全的做法是為所有更新操作無論是byId還是byWrapper都添加一個必須帶有WHERE條件的檢查可以在公司基礎(chǔ)框架層面對此進(jìn)行約束。5.3 與MyBatis原生功能沖突現(xiàn)象自定義的XML映射文件中的SQL不執(zhí)行或者M(jìn)P的自動填充在自定義SQL中不生效。排查與解決Mapper接口繼承沖突你的Mapper接口既繼承了BaseMapper又定義了同名方法。例如UserMapper中有一個selectById方法這會導(dǎo)致MP生成的實現(xiàn)與你XML中定義的SQL沖突。解決方法是為自定義方法起不同的名字或者在Mapper注解中指定不同的mapper.xml命名空間。插件攔截范圍MP的插件如分頁、樂觀鎖、多租戶默認(rèn)只攔截由MybatisPlusInterceptor配置的Executor的方法。如果你在XML中寫了一個select id“customQuery”分頁插件默認(rèn)是不會對其生效的。如果需要讓自定義SQL也支持分頁需要在XML的SQL里使用MP提供的${ew.customSqlSegment}并在接口方法參數(shù)中用Param(“ew”)傳入Wrapper。select id“selectUserPage” resultType“User” SELECT * FROM user ${ew.customSqlSegment} /selectIPageUser selectUserPage(IPageUser page, Param(“ew”) WrapperUser wrapper);5.4 枚舉類型映射處理MP對枚舉類型有很好的支持。默認(rèn)情況下它會使用枚舉的name()值字符串與數(shù)據(jù)庫字段進(jìn)行映射。如果你希望存儲枚舉的ordinal索引或者自定義的code值可以使用EnumValue注解。public enum StatusEnum { ENABLE(1, “啟用”), DISABLE(0, “禁用”); EnumValue // 標(biāo)記這個字段的值存入數(shù)據(jù)庫 private final Integer code; private final String desc; // 構(gòu)造方法、getter省略 }在配置文件中還需要指定枚舉處理的默認(rèn)規(guī)則mybatis-plus: configuration: default-enum-type-handler: com.baomidou.mybatisplus.core.handlers.MybatisEnumTypeHandler5.5 分布式環(huán)境下的ID生成與數(shù)據(jù)一致性MP默認(rèn)的IdType.ASSIGN_ID策略使用的是雪花算法這本身就是為了分布式環(huán)境設(shè)計的能保證在分布式系統(tǒng)內(nèi)生成全局唯一、趨勢遞增的ID。但需要注意機(jī)器時鐘回?fù)軉栴}雖然MP使用的DefaultIdentifierGenerator有一定處理但在極端情況下仍可能產(chǎn)生重復(fù)ID。對于金融等高要求場景可以考慮接入更嚴(yán)格的分布式ID服務(wù)如美團(tuán)的Leaf或百度的UidGenerator。對于數(shù)據(jù)一致性MP提供了樂觀鎖插件OptimisticLockerInnerInterceptor通過一個Version注解字段來實現(xiàn)。在更新時會自動帶上version oldVersion條件并在成功后newVersion oldVersion 1。這是一種無鎖化的并發(fā)控制手段適用于讀多寫少、沖突不激烈的場景。如果沖突頻繁則需要考慮悲觀鎖或更復(fù)雜的事務(wù)方案。從我個人的使用經(jīng)驗來看MyBatis-Plus的成功在于它在“便捷”和“靈活”之間找到了一個絕佳的平衡點。它沒有像JPA那樣試圖用一套復(fù)雜的規(guī)范屏蔽所有數(shù)據(jù)庫細(xì)節(jié)而是尊重了MyBatis SQL可控的精髓然后在此基礎(chǔ)上把那些重復(fù)、枯燥、易錯的部分用最優(yōu)雅的方式自動化了。掌握它的核心思想——條件構(gòu)造器、插件體系、元對象處理——比死記硬背API更重要。最后記住任何工具都有其邊界在遇到MP無法優(yōu)雅解決的超復(fù)雜SQL或特定數(shù)據(jù)庫高級特性時毫不猶豫地回歸到MyBatis原生的XML/注解方式這才是MP設(shè)計哲學(xué)倡導(dǎo)的“自由”。