string CacheManager.addRule(string|RegExp|Object rule)
添加規則。

基礎庫 2.23.0 開始支持，低版本需做兼容處理。
小程序插件：不支持
參數
string|RegExp|Object rule
規則

返回值
string
規則 id

規則說明

支持的規則寫法有字符串、正則和對象三種：

字符串寫法
addRule('/abc')：純 uri 串。
`addRule('GET /abc')：帶方法的 uri 串，除了匹配 uri 外，還會匹配請求方法。如例子中必須是 GET 方法請求才會被匹配。
addRule('/abc/:id')：帶可變部分的 uri 串，id 可以是任意符合標準的字符串，表示這一段可以動態變化。比如/abc/123<code>和/abc/321都會被匹配，而/abc/123/xxx` 因為多了一段，就不會被匹配。
addRule('/abc?aa')：帶 query 參數的 uri 串，包含 aa 參數，值可以為任意值。比如/abc?aa=haha<code>會被匹配，但是/abc就不會被匹配，因為缺少規則中聲明的 aa 參數；不過如果請求是/abc?aa=haha&bb=123`，雖然多帶了 bb 參數，但是因為包含了 aa 參數，所以也可以被匹配。
addRule('/abc?dd=haha')：帶 query 參數的 uri 串，包含 dd 參數且值為 haha。比如/abc?dd=haha<code>和/abc?dd=haha&bb=123會被匹配，而/abc?dd=123` 就不會被匹配，因為規則要求了 dd 參數的值。
以上寫法中的 uri 串如果只有 path 部分，則會取全局 origin 進行補全。比如全局 origin 是 https://weixin.qq.com，而規則是 <code>/abc，則會補全為 https://weixin.qq.com/abc。因此在前面例子中 <code>addRule('/abc') 和 addRule('https://weixin.qq.com/abc') 的寫法效果一致。所以一般情況下如果需要匹配的請求 origin 和全局 origin 一致，則規則中可忽略不寫 orign。
正則寫法
addRule(/\/(abc|cba)$/ig)：直接正則匹配請求的 uri，同時會比對請求 origin 和全局 origin 是否一致。
addRule(/^https:\/\/weixin.qq.com\/(abc|cba)$/ig)：帶有 orign 部分的正則表達式，則只匹配 uri，不再比對 origin。
對象寫法

使用規則對象，可以更為詳細的描述規則內容。（一般使用規則對象，是為了匹配請求參數）

規則對象：
屬性名    類型    默認值    備注
id    string        規則 id，如果不填則會由基礎庫生成
method    string        請求方法，可選值 GET/POST/PATCH/PUT/DELETE，如果為空則表示前面提到的所有方法都能被匹配到
url    any    必填    uri 匹配規則，可參考規則字符串寫法和正則寫法
maxAge    number    7 * 24 * 60 * 60 * 1000    緩存有效時間，單位為 ms，不填則默認取緩存管理器全局的緩存有效時間
dataSchema    Array<DataRule>        匹配請求參數
其中，dataSchema 用來匹配請求參數（比如 wx.request 的 data），默認可以不填，即不做參數匹配。

dataSchema 的類型是一個 DataRule 對象數組，一個 DataRule 對象描述一個參數，比如一個 wx.request 請求的 data 是 {a: 123, b: 'haha', c: true}，你想要用一條規則來匹配其中的 a 和 b 參數，如果 a 是數字且 b 是字符串就能命中該規則，那么就需要在 dataSchema 中補充兩個 DataRule 對象，即 <code>[{name: 'a', schema: {type: 'number'}}, {name: 'b', schema: {type: 'string'}}]。

DataRule 對象：
屬性名    類型    默認值    備注
name    string        需要匹配的參數名
schema    DataSchema/Array<DataSchema>    需要匹配的參數模式，支持數組，表示該參數值有多種模式    
name 表示要匹配的參數名，schema 為 DataSchema 對象，用來描述該參數的類型和值。


一個 DataRule 對象也可以匹配可能擁有多種類型的參數，所以 schema 也支持為 DataSchema 對象數組。比如上述例子中，希望匹配的 a 參數必須是數值或者字符串，那么可以這么寫：{name: 'a', schema: [{type: 'number'}, {type: 'string'}]}。

DataSchema 對象：
屬性名    類型    默認值    備注
type    string        需要匹配的 data 對象的參數類型，string、number、boolean、null、object、any（表示任意類型），同時支持數組模式（數組模式則在類型后面加 []，如 string[] 表示字符串數組）
value    string/regexp/function/Array<DataRule>        需要匹配的 data 對象的參數值，當 type 為基本類型時，可以用 string/regexp 來匹配固定的值，也可以通過 function 來確定值是否匹配，如果傳入的 type 是 object，那么表示需要嵌套匹配值是否正確，可以傳入 Array
type 參數表示要匹配的參數類型，value 表示要匹配的參數值。其中 value 支持多種寫法，不同寫法有如下匹配方式：

字符串寫法：直接判值的字符串形式是否和給定字符串一樣，比如 value 值為 123，就要求參數值必須為 123 才能與之匹配。
正則寫法：直接判值的字符串形式是否能被正則匹配，比如 value 值為 /\d+/ig，就要求參數值必須為數字，如果參數值為 <code>abc 則不會被匹配。
函數寫法：在匹配時會調用用戶傳入的函數，交由用戶判斷是否匹配。
DataRule 數組寫法：當參數類型為對象時，那么字符串寫法和正則寫法就無法使用，需要傳入 DataRule 數組來進行匹配，即通過嵌套 DataRule 數組的方式來匹配嵌套的對象。
示例代碼

const ruleId = cacheManager.addRule({
  id: 'haha-rule',
  method: 'GET',
  url: '/haha',
  maxAge: 123455,
  dataSchema: [
    // data 字段的匹配，默認為空，表示不匹配
    // 類型可以是：string、number、boolean、null、object、any（表示任意類型均可），以及這些類型的數組表示方式
    {name: 'aaa', schema: {type: 'string'}}, // 類型為 string
    {name: 'bbb', schema: [{type: 'number'}, {type: 'string'}]}, // 類型為 number, string
    {name: 'ccc', schema: {type: 'string', value: 'abc'}}, // 值為 abc
    {name: 'ddd', schema: {type: 'string', value: /(abc|cba)/ig}}, // 值符合該正則匹配，如果該值不是字符串類型，則會被嘗試轉成字符串后再進行比較
    {name: 'ddd', schema: {type: 'string', value: val => val === '123'}}, // 傳入函數來校驗值
    {name: 'eee', schema: {type: 'object', value: [{ // 類型為對象，則通過嵌套的方式來逐層校驗
      name: 'aaa', schema: {type: 'string'},
      // ...
      // 嵌套 dataSchema，同上面的方式一樣來匹配嵌套的對象
    }]}},
    {name: 'fff', schema: {type: 'string[]'}}, // 類型為 string 數組
    {name: 'ggg', schema: {type: 'any'}}, // 類型為任意類型
    {name: 'hhh', schema: {type: 'any[]'}}, // 類型為任意類型的數組
  }],
})
補充說明

用戶可以添加多條規則，每條規則都會去解析網絡請求，然后判斷是否命中規則。假設有多條規則命中，則取第一條命中的規則。

緩存覆蓋
不同的網絡請求也可能命中同一條規則，所以每條規則可能對應多個緩存。每條規則會有一個規則 id，每個緩存會有一個緩存 id，一個規則 id 可能對應多個緩存 id，而緩存管理器的緩存存儲是基于緩存 id 標識的，如果兩個不同的請求生成了同樣的緩存 id，那么后發生的請求結果緩存會覆蓋前者。因此使用時需要思考緩存的覆蓋情況，目前緩存 id 生成方式如下：

規則使用字符串寫法：那么按 method + url + 規則中聲明的 query 參數來生成緩存 id。
需要注意的是這里不使用真實請求中的 query 參數來生成緩存 id，而是使用規則中匹配到的 query 來生成緩存 id。比如規則是 /abc?aa=123，請求是 GET 方法的 <code>/abc?aa=123&bb=123，那么就會基于 GET /abc?aa=123 來生成緩存 id。而規則里沒有聲明 <code>bb=123，所以 bb 參數不會被納入緩存 id 的生成基準。
規則使用正則寫法：那么只按 method + url 生成緩存 id，不考慮 query 參數。
規則使用對象寫法：如果規則對象中的 url 是字符串寫法，那么按 method + url + 規則中聲明的 query 參數 + 規則中 dataSchema 聲明的請求參數來生成緩存 id；如果規則對象中的 url 是正則寫法，那么按 method + url + 規則中 dataSchema 聲明的請求參數來生成緩存 id。
生成緩存 id 時沒有使用請求中完整的 query 參數或者請求參數來作為基準，是考慮到很多請求可能會帶上 token 或時間戳等參數。因為此參數存在不確定性，會導致每次請求生成的緩存 id 都不同，進而導致緩存命中率下降，故采取規則中聲明的 query 參數和 dataSchema 聲明的請求參數來作為生成緩存 id 的基準。