Debug龍爪手(3)
前端：
一定要先確認device和使用的browser，把你遇到的問題打在google上，很可能後面就會接safari出來。
通常可以在f12看到紅字，如果你很確定不是你的code的問題，要再往gtm或是其他第三方動態載入的js去找問題。
最好要用無痕或是手動清cookie也試試看。因為我們有走cloudflare，所以也有機會是cloudflare問題，可以上去看機器ip，去改一下本機etc/hosts ，直接指向機器，跳過cloudflare。
排除gtm方式:搜gpt，封鎖他
後端：
先去elk看log，如果沒有LOG，可以加一些debug參數，只有吃到某個參數的人會在頁面上輸出sesson或是data，還有設斷點，或是直接倒資料重現問題，就看哪個比較快，其他因為我們有用laravel和一些套件，有時候也要注意一下去改vendor的程式看看狀況，在vscode搜尋時，要記得把右下那個 — 拿掉，才會去搜git ingrone的檔案。
資料庫：
通常在ELK也會看到log，連線失敗，執行過久，都沒有的話要看看是不是有用到讀寫分離，要去看一下slave有沒有複寫延遲，也可以去問問看infra有沒有看到slowquery。
也可以自己查看
可以自己再篩選db
redis cache :
redis有機會掛掉，無法連線。平常更新程式時，也很容易忘記要清cache去測試，因為有機會你上完程式會正常，是因為還吃到前面的cache。另外就是cache有機會會滿，如果滿了，就算你是寫cache forever，也有機會被擠掉，一定要考慮到這種情境。
還有一個要注意的問題，cache失效時，或是cache的內容失效要重新寫入時，要小心可能會有多點觸發的問題，有可能會同時一堆人在做寫入cache，或是最終的cache不是最新的狀況，可以用cache lock來做補強 ex:重取會失效的token。
redis cache＋資料庫：
在讀寫分離下，在write寫入資料，然後清除cache，但是卻從read補cache，會有機會踩到複寫延遲問題。
上面提到的cache多點觸發的案例，也會發生在db回補cache的情況上，假設sql無法瞬間完成，那很有機會一堆人衝進來同時再做db回補cache的動作，最終可能會整個塞車，無法消化，如果是這類型的cache，也可以用cache lock補強，或是要注意不該讓cache失效，透過排程來回補
cdn cache：
cloudflare的cdn有幾個東西要注意，如果是不存在的檔案，他會cache成空白內容（和設定有關）。
client cache：
靜態檔未換檔名，在不特別設定cache control的情況下有機會走到client cache，一般我們在開發時會開者no cache，很容易會忘了有clinet cache這件事，css js如果有更動，最好要換檔名或加上?版號，也要注意是不是上版號就有用，因為還有上面提到的cdn cache。
網路 ：
重複請求是很平常的事。
確認一下你vpn狀況，vpn也是會壞的。
有時候在公司模擬不出狀況，可以試著用自己的4g網路看看有沒有新天地。
設備故障：
走雲端一樣有機會機器硬體故障，不過這邊還沒遇到。
