1、通常情況下，如果要在組件中處理一個屬性數據，有兩種方式
1、使用監聽器：observers（推薦）
observers: { 'data':function(data){ } },2、在小程序的生命週期函數中操作：
data: { }, /*新式寫法*/ lifetimes:{ attached(){ } }, /*老式寫法*/ /* attached(){ }, */ methods: { }小程序頁面自定義組件的生命週期初始化函數不是 onload，而是 attached(){} ，在某些情況下可以在該生命週期函數中處理 properties 的數據，但該函數不能一定保證數據已經傳遞進來。
2、數學對於編程來講，到底重不重要？
可以肯定的是，英語對於編程來講，幫助無疑是最大的。籠統地講，數學對於大部分編程概念是很重要的，但多數人做的都是 web 開發，如果不是特別的場景，web 開發對於數學的依賴並不大
數學方面對編程作用最大的當屬：線性代數中的矩陣、概率論與統計（排列組合） 這兩個內容。
但就算是用到上述的兩個內容，也只是非常淺的應用，並不能談得上算是對數學的真正應用。
所以不是說數學不好，編程就做不好。（等你把數學、英語補好了之後，估計離退休也不遠了）
3、矩陣的轉置與旋轉
1、旋轉：把一個矩陣按照指定方向旋轉（90 的倍數旋轉）
2、轉置：與旋轉是不一樣的，它把一個矩陣裏面的某一個元素的行號和列號進行互換。（對角線上的元素位置是不變的）
3、旋轉 90 度 與轉置後的結果是不一樣的。
4、小程序類是直接返回二維數組還是返回一個類？
當這個類不僅僅只有數據，還需要相關操作方法的時候，優先選擇返回一個類
5、能通過調試解決的問題，都不能算得上問題。典型的真正問題可以舉幾個栗子
1、原理性的
2、知識性的
3、邏輯思維性的
6、JS 中的 防抖 和 截流
7、分頁的封裝
1、做分頁要考慮的細節太多了，所以考慮將其封裝好
2、如何開展封裝？（借鑑了 生成器設計模式）
① 我們期望的是什麼？期望的是頁面或者自定義組件去調用分頁的時候，應該足夠的簡單，而不是每一次都考慮這麼多細節
② 封裝的方式有兩種：第一是以類爲核心的思想；第二個是以函數爲核心的思想。（如果ES6沒有出現，或者它沒有提供類的概念，可以用ES5 的函數作爲主體封裝）
③ Paging 對象自行處理到第幾頁，外部不關心細節，外部需要下一頁的時候，就調用Paging對象的獲取更多數據接口即可
④ Paging 是以 “ 實例 ” 還是 “ 靜態 ” 的方式提供給調用方？很明顯Paging一定要保存狀態，所以更多時候是要以實例化的形式提供給調用方，也即在調用方調用時需要 new Paging，只有 new 出來的才能保存狀態
⑤ 對象的屬性是可以保存狀態的，那麼這個Paging需要什麼屬性呢？
- start
- count
- url
⑥ 第一次向服務器發送請求
- getLocker（判斷鎖）
- request（獲得鎖並鎖上，然後發請求）
- releaseLocker（釋放鎖）
8、爲什麼服務端有時候不需要提供某一個商品的規格名所對應的可選規格值？比如不會提供“顏色” 這個規格名對應的規格值
因爲所有的信息都統一返回了，不需要再單獨提供，前端處理即可
9、some函數 和 every函數
some 和 every 都會遍歷數組，但有一個區別：
- some 只要求數組下某一個元素符合 所給出的條件，就會馬上返回，否則才返回 false
- every 不同，它要求數組下所有的元素都滿足給定的條件，纔會返回true，否則返回 false
10、flex 佈局爲什麼能把原來的塊級元素變成了類似 inner 的行內元素
其實整個 view 的元素都應用了 flex 佈局之後，每一個元素就相當於 flex 的一個 item，這也是 flex-item 的 特性，如果沒有指定元素的寬度，那麼 flex-item 就會根據內容來自適應。
對於 flex 來說，它下面的子元素，要理解成 flex-item，也就是 flex 的子項，而 flex 子項是有相關特性的
11、SKU的難點
SKU算法是爲了體驗
核心問題在於規格的狀態：可選、選中、禁用
難點在於：確定規格的禁用狀態
12、SKU算法剖析
- 確定可選與已選是比較簡單的，要確定禁用的狀態，可以從用戶的行爲來推演
- 假如現在不去考慮默認的SKU，因爲默認的狀態會讓SKU更爲複雜
- 如果沒有默認的SKU，那麼所有的按鈕（每一個規格）都應該是可選的狀態
- 用戶必須從已有的規格值中各選一個才能組成一個唯一單品，
①、每當用戶選擇一個規格， 那麼此時就去確認其他行的規格到底是可選還是禁用狀態
②、怎麼去確認呢？ 把已選規格再加上另外一行的規格，這兩個規格會形成一個待確認的SKU路徑，只需要去確認這個待確認的SKU路徑是否存在，就可以判斷這個待確認的規格到底是禁用的還是可選的
③、最開始的時候，所有的規格都是可選的，任意選擇一個規格，如何確定其他規格呢？比如選擇一個青色，然後將青色與其他規格比如 龍的圖案，去查找一下，青色+龍圖案 到底在不在SKU的路徑中，如果在，那麼 龍圖案就是可選，反之則禁用。
④、假設青色+龍圖案 的SKU路徑存在，那麼再進一步確定剩餘的規格比如尺碼。青色+龍圖案 再加上一個待確認的規格，就組成了三個規格的路徑，此時再去判斷這三個規格的路徑是否存在，從而確定尺碼
⑤、可以確定出兩個概念，也就相當於兩個字典（抽象化理解）
- 待確認的SKU路徑
- 已存在的SKU路徑
⑥、每一次生成一個待確認的SKU路徑，都去這個字典裏查找一下，能查找的到，就認爲SKU路徑是存在的，反之則需要禁用某些規格值
⑦、如何確定字典中的內容？如果無法確定字典的內容，SKU路徑也是無法確認的
- 已存在的SKU路徑需要全部提取出來，相當於一個集合
- 有了這個集合，每一次生成待確認的SKU路徑都去集合中查找，從而判斷它是否存在
⑧、假如已存在的SKU路徑全部提取出來了，待確認的SKU路徑如何確定？比如要去字典中查找一些字，字典已經有了，但是要查哪些字？要查哪些字也是需要去確認的
⑨、可能存在的待確認SKU路徑是如何確定的？
- 所有的規格都是可以選擇的，除非有默認規格
- 比如用戶選擇了青色，待確認的路徑有哪些？青色+龍圖案、青色+鼠圖案、青色+豬圖案都是待確認的SKU路徑
- 除了上述3個待確認的路徑外，還有別的待確認路徑嗎？
- 在判斷完圖案的待確認路徑後，就可以確定圖案的禁用狀態了
- 假設青色+龍圖案是不存在的，用戶會進行二次選擇，比如用戶點擊了鼠圖案，下一步就是確定下一個規格的禁用狀態，比如下一個是尺碼，此時待確認的路徑又有哪些？
- 青色+鼠圖案 肯定是要作爲路徑的一部分，再加上 S、M、L又各是一種待確認的路徑
⑩、以上的問題在於
- 當用戶在選擇了青色之後，只是判斷了圖案的待確認路徑，而少判斷了其他規格的待確認路徑。（線性思維限制）必須要考慮到的是用戶並不是按順序來選的，選擇是具有隨機性的
- 只是計算了兩個節點的待確認路徑，也就是顏色+圖案、顏色+尺碼，必須是先計算用戶已選的規格+其他一個規格，然後再計算已選規格+剩下規格。
- 用戶進行第二次選擇之後，比如用戶選擇了鼠圖案，還需要計算一次
⑩①、當用戶第二次選擇了圖案，還需要再計算一次顏色+圖案，顏色＋尺碼的選擇嗎？
顏色+尺碼之前不是計算過了嗎，狀態不是已經都確定了嗎？那麼用戶在確定了青色+鼠圖案的時候，爲什麼還要再一次確定顏色+尺碼呢？
- 假如用戶選擇了 青色，青色+尺碼、青色+圖案的待確認路徑都要計算一次，從而確定禁用狀態
- 假如青色+鼠圖案的路徑是存在的，鼠圖案被確定爲可選，那麼很有可能是 青色+s 的路徑也是存在的
- 但之前選擇顏色的時候，已經計算過了，S 是被禁用了。因爲假設青色+S是存在的，那麼此時用戶選擇圖案的時候又確定了一個鼠圖案，雖然說青色+S路徑是存在的，但青色+鼠圖案+S路徑是有可能不存在的
- 雖然曾經確定過S的狀態，但是一次確定不代表S永遠是禁用狀態，S的禁用與否是和已選規格緊密相關的，其他規格的狀態都是有可能改變的
- 所以每一次的選擇，都需要將規格重新計算一次
⑩②、問題是否已經全部解決了呢？
- 當用戶第二次選擇了鼠圖案之後，會去計算青色+鼠圖案+尺碼的組合，但是鼠圖案也是一個被選中的規格，那鼠圖案+豬、鼠圖案+龍之間也是有可能是存在確定路徑的，用青色+鼠圖案+尺碼的方式是爲了算出尺碼的狀態。問題是鼠圖案+豬也是需要去再次計算狀態的
- 既然計算鼠圖案+尺碼的組合，爲什麼不計算鼠圖案+豬、鼠圖案+龍之間的組合？
⑩③、其實是典型的線性思維導致12點的遺漏，因爲潛意思裏總會想着用戶按順序選擇，並且用戶已經選擇了一個顏色，選擇其他規格的時候，顏色幾句不會再改變了。
⑩④、如何計算呢？
- 每當用戶做了一個已選中規格的改變之後，所有的規格值都需要去重新確定狀態。
13、默認SKU的概念與意義
- 初始化時，用戶沒有選擇SKU，那就無法確定各種規格的狀態
- 假設商品的所有規格都是可選的，但問題是商品可能只有一款，此時是沒有SKU的（或者說是無規格的），需要處理無規格的情況（重要）
- 嚴格意義上來講，所有的商品都至少有一個規格
14、溝通類與本職類
在複雜的業務中，有一些溝通類，是自行抽象出來，負責在本職類之間去溝通的類
15、如何讓代碼簡潔易懂
- 儘量少寫顯式的for循環（[].map 是隱式的for循環）
- 實在無法避免兩層for循環時，可以把內層for循環單獨封裝成一個類的方法或者封裝成函數，在外層for循環調用該循環
16、在原生事件中再觸發自定義事件？
事件的應用有着非常重要的意義，就是從子組件向父組件傳參
父組件向子組件傳參是通過子組件的 properties
子組件向父組件回傳參數的時候，就需要事件來傳遞，原因很簡單，用戶點擊了之後，用微信原生的tap事件，只能侷限在properties 定義的屬性內部，屬性內部知道用戶點擊了之後的數據是沒有意義的，因爲屬性是一個獨立的個體。
17、引用類型
比如定義了一個a，const a = {c: 1}，此時將a賦值給另一個變量b，const b = a，如果修改了b，b.c = 2，此時 a.c也會變成2
18、如果是無SKU的情況，但確實又存在着多種不同類型的商品，如何處理
把不同的類型當做是兩個SPU，比如：提拉米蘇 8寸，由於沒有SKU的概念，所以直接把這個 “提拉米蘇 8寸” 當做一個SPU，然後再有 提拉米蘇 10寸，這原本有SKU的情況下是同屬一個SPU的不同SKU，但在無SKU的情況下，提拉米蘇8寸 和 提拉米蘇 10寸 是兩個SPU
19、SKU 概念必須要有，可以沒有規格。爲什麼必須至少有一個SKU？
因爲要代碼的統一邏輯處理，如果說有的商品有SKU，有的商品沒有SKU，實際上代碼非常難以處理。
所以對於無規格的定義是：某一個商品如果是無規格的，至少需要有一個SKU，但是這個SKU是可以沒有規格的。
對於無規格來說，SPU下應該是隻有一個SKU，同時SKU的下面是沒有任何規格的。
20、用戶選擇規格，與顯示、提示的聯動分哪幾種情況
- 如果是整個SKU完整路徑的切換，圖片、標題、價格、庫存、已選規格值都要發生變化
- 如果不是完整的SKU路徑切換，商品的顯示數據如何改變？容易讓人想到的是，如果SKU路徑不完整，那麼顯示、提示都置空；或者將顯示的數據切換成SPU
- 如果SKU路徑不是完整的，那麼以前的數據狀態是怎麼樣的就保留以前的數據狀態，直到用戶再次確定了完整的SKU路徑之後，再進行SKU商品的顯示切換（推薦）
21、什麼樣的代碼應該重構？
當一個函數的行達到20多行的時候，就應該可以考慮重構了（僅個人愚見）
22、性能：setData性能探討
頻繁調用setData，會對性能造成一定的影響，但setData多次，對用戶體驗影響並不大。
一次數據渲染，原則上情況都麼複雜，其實都應該只setData一次。
如果所有的setData都強制要求永遠只setData一次，代碼將會變的異常複雜難懂以及難以維護
setData次數一定是可控的
23、當我們談編程能力的時候，我們談的是什麼（換句話說就是，憑什麼你就比別人強）
- 更注重的並非會多少個框架，而是編程能力和思維的培養，要培養編程能力，首先要搞清楚什麼纔是編程能力
- 比如小程序中的外部樣式類，懂的人不少，但能把外部樣式類放到解決實際問題的場景中確實很少，這並非知識多寡的問題
- 一個簡單的東西是否有對其深入的理解，當你對它有深入理解之後，是否會嘗試着把它用來解決其他問題呢？這應該是能力強和能力差的本質區別
- 能力強的人是學這個東西爲了解決實際問題，而不是爲了面試。很多人都是面向面試編程，學的東西很多都是死記硬背，結果上手能力和動手能力非常差
- 學習編程不應以面試爲目的，動機一定是要爲了能解決問題
- 可以爲了面試而突擊學習，這不成問題。但一定要不忘初心也即不能忘記編程的目的是爲了解決實際問題，做出好的項目和產品來
24、如何鍛鍊解決問題的能力？
- 動機不能放在面試上，切忌死記硬背。
- 只有有了正確的動機，纔能有後面的發展。
- 解決問題，說一千道一萬，還是要多做項目，而且要做高要求高質量的項目。
- 每一個細節都要去挖掘，都要做好，只有給自己定一個很高的標準，才能鍛鍊自己解決問題的能力
- 如果什麼都是淺嘗輒止都是demo，而沒有細節方面的考慮，解決問題的能力是永遠得不到提高
- 沒有好的項目，沒有真實項目怎麼辦？自己模擬一個項目出來，或者自己對比優秀教程的解決問題思路與方法
25、規格的主觀性與組合性
主觀性
- 比如說對於牛仔褲來說，不同的商家最終編輯出來的規格可能是完全不一樣的，有的商家確定了顏色和尺碼兩個規格，並不是說所有的的商家最終確定的規格都是顏色和尺碼。
- 尺碼也是一樣的，按照標準尺碼來說，有XS、M、L、XL，商家的商品可能就沒有這麼多的尺碼，只有大碼和小碼。
- 規格的確認是根據商品在某個商家裏實際情況來決定，並不都是標準的
組合性（被大量應用於淘寶中）
- 淘寶商家編輯商品規格時，並非一個規格就是一個規格，可能商家確實有很多種規格，但商家有可能會有意的把多個規格組合成一個規格，通過規格的組合來讓用戶進行規格的選擇
26、可視規格的概念
- 如果在衆多的規格中，某個規格上直接顯示圖片，那麼這些規格就稱之爲可視規格、
爲什麼要有可視規格？
- 在有可視規格的情況下，任何一個規格都不用選中，就可以看到商品的所有規格是長什麼樣子的
- 如果沒有可視規格時，所有的規格都需要選一遍才知道各個規格是長什麼樣子的
27、組件內部數據如何傳輸到組件外部並在組件外部頁面接收？
通過自定義事件，將數據類似冒泡的形式拋出來，在組件外部頁面監聽該事件
28、用僞類模擬製表符效果