01｜GitHub Actions：公開專案的 pull_request_target 政策

11/02 公告｜12/02 生效

GitHub.com 公開 repository 的 pull_request_target 將預設遭封鎖，除非適用的 Actions event policy 明確允許。Private、internal repository 與 GitHub Enterprise Server 不在本次範圍。此事件能接觸 base repository 的權限與 secrets，執行 fork 的不可信程式碼尤其需要審慎。

先做什麼： 搜尋 workflow 的觸發事件，查看 Actions Insights 的影響紀錄。優先評估 pull_request；必要例外應限縮到特定 workflow。兩次短暫強制測試為台灣時間 11/10、11/17 的 00:00–02:00，第一次已過。

官方公告

02｜Gemini Code Assist：既有綁定權益將結束

11/06 公告｜2027/03/31 截止

既有 Gemini Enterprise Standard／Plus 訂閱附帶的 Code Assist 權益將於 2027/03/31 移除，在此之前僅支援 Gemini 3.x 模型系列。自 10/09 起，新訂閱已不再附帶該權益；Google 提出 Antigravity 作為開發流程的遷移選項。

先做什麼： 核對授權來源，再評估替代工具。這不是所有 Code Assist 授權都在同一天停用的公告，獨立訂閱需另查適用條款。

Gemini Enterprise 發布紀錄

03｜OpenTelemetry JavaScript SDK 3.0

11/05 發布

最低 Node.js 版本提高至 22.15.0，停止支援 Node.js 18、20；改善 ESM／CommonJS 匯出，將 Logs API 納入 @opentelemetry/api，並整併 tracing SDK。部分舊相容套件與 API 移除。穩定版 SDK 2.x 在 3.0 發布後仍有一年支援。

先做什麼： 盤點 Node.js runtime、exporter 與 @opentelemetry/* 相依版本，依 migration guide 測試 traces、metrics、logs。這次變更不要求 Python SDK 一併升級。

官方發布與遷移說明

04｜Container-Optimized OS：LTS 安全更新

11/06 發布

COS 125、129 發布 LTS refresh，包含系統與容器相關元件修正。COS 125 的映像版本為 cos-125-19216-801-14；實際漏洞清單、runtime 與 kernel 版本應依使用的 milestone 核對，不能跨映像套用。

先做什麼： 查明主機 boot image，安排支援的更新與必要重啟，先驗證容器能正常啟動。Ubuntu、Debian 等其他映像不適用這份 COS 修補清單。

COS 125 發布紀錄 · COS 129 發布紀錄

05｜API Gateway：Streaming backend 認證調整

11/03 發布

啟用 streaming 的 gateway，對主機名稱以 .googleapis.com 或 .vertexai.goog 結尾的 backend，改用 gateway service account 的 access token；其他 backend 仍接收 ID token。既有 gateway 會在平台下次更新，或切換新 API config 時套用。

先做什麼： 使用 Vertex AI 等 Google API backend 的流程，應測試 token 類型、IAM 權限及更新後的認證結果。未使用 streaming gateway 者不必為此修改服務。

API Gateway 發布紀錄

06｜Claude Code 2.1.319：Auto Mode 與 MCP 背景任務

11/06 發布

部分停用 telemetry／feature flag 或使用 LLM gateway 的 Auto Mode 情境，伺服器無法檢查的工具呼叫會改為詢問或拒絕，不再自動回退至內建分類器。Bedrock、Vertex、Foundry 的相關行為不變。新版也支援 MCP task 背景執行、permissions.denyInsteadOfPrompting，以及 /claude-api latency-optimize。

先做什麼： 升級前測試非互動式流程的授權、MCP 任務完成通知與失敗恢復，不要為了讓流程跑完而全面放寬權限。

v2.1.319 release

07｜Claude API：IP Allowlist Beta

11/05 發布

Claude Console 可設定組織層級的 IP allowlist，支援 IPv4、IPv6 與 CIDR，每組織最多 1,000 項。受涵蓋服務會拒絕清單以外的來源，降低 API key 外洩後可被使用的範圍；仍須確認服務涵蓋限制。

先做什麼： 先盤點出口 IP，再測試固定 NAT 與來源限制。使用動態出口的工作負載若直接啟用清單，可能被自己擋下。

Claude Platform 發布紀錄

08｜Agent Registry：Skill 版本與安全治理 GA

11/06 發布

Standalone skills 正式 GA，提供 Skill、不可變的 SkillRevision、publisher 資訊，以及註冊、搜尋與版本管理。安全掃描可產生 findings，搭配 Organization Policy 與 IAM 控制使用；skill payload 的 CMEK 保護仍為 Preview。

先做什麼： 以少量共用 skills 測試版本固定、來源審核、掃描結果與最小權限。掃描通過不等於可免除人工檢查。

Agent Registry 發布紀錄

09｜Claude Messages API：Message Threads Beta

11/02 發布

伺服器可暫存對話，後續請求只傳新增訊息，減少 payload 並改善首 token 延遲。使用 message-threads-2026-08-12 beta header；thread 在最後請求後 5 分鐘過期，最後使用後最多 1 小時內刪除。

先做什麼： 用多輪 tool calling 比較延遲、傳輸量及失敗恢復。它不是長期記憶或永久對話儲存。

Claude Platform 發布紀錄

10｜Cloud Run：Ephemeral Disk GA

11/04 發布

Cloud Run ephemeral disk 已正式 GA，可在 service、job 或 worker pool 掛載只存續於該 instance 生命週期的磁碟 volume。適合文件轉換、批次作業或其他中間產物，不是永久儲存。

先做什麼： 測試容量、效能、費用及 instance 結束後的資料處理。需要持久化的成果應另存 Cloud Storage 或資料庫。

Cloud Run 發布紀錄

11｜OpenAI：GPT-6 Cyber

11/05 發布

API changelog 新增 gpt-6-cyber，用途包括漏洞調查、在已授權測試環境重現問題，以及驗證修補。首次使用前需閱讀 Daybreak 設定與存取要求。

先做什麼： 先確認資格與授權範圍，再用隔離測試環境評估結果。模型產出不能取代人工驗證，也不應直接對未授權系統執行測試。

OpenAI API Changelog

12｜Codex CLI 0.167.0：Agent Command Center

11/06 發布

新增 codex agents --no-daemon，可在 command center 與 session picker 辨識未讀結果、切換 backend，並在支援的終端機預覽本機圖片。實驗性的 gcp_setup_wizard 協助設定 Vertex AI 的 ADC 或憑證檔案。

先做什麼： 測試多 backend 切換、對話恢復與認證權限。這是 CLI 版本更新，不代表每項功能都已同步到桌面 App。

0.167.0 release

13｜Gemini CLI 0.67.0：MCP 權限與 Sandbox 修正

11/04 發布

新增 models 指令與 --list-models，改善容器 sandbox 的 IDE companion 連線，修正唯讀檔案／hard link 寫入處理，以及非互動模式取消後仍繼續執行工具的問題。ACP 權限請求現在包含 MCP server 與 tool metadata。

先做什麼： 測試檔案保護、取消行為和 MCP 授權畫面，尤其是把 CLI 接入自動化的流程。

v0.67.0 release

14｜Copilot Code Review：API 管理與來源追蹤

11/06 發布

REST／GraphQL API 擴充到企業、組織與 repository 的 code review 設定，並能辨識 Copilot review／comment、review effort，以及回報的 skills、MCP、自訂指令來源。不同管理層級的權限不同；企業與組織設定端點尚不支援 GitHub App 或 fine-grained PAT。

先做什麼： 用測試 repository 比較審查品質、誤報與人工修改時間，再決定是否擴大使用。來源資訊是可追蹤線索，不是結果正確性的保證。

GitHub 官方公告

15｜Dependabot：支援 Agent Package Manager

11/03 發布

Dependabot 可更新 apm.yml 中受支援的 git 相依項目，並在存在時重建 apm.lock.yaml，將 skills、prompts、instructions 的版本更新納入 PR。這次支援的是版本更新，不包含安全漏洞更新。

先做什麼： 有使用 APM 才需要新增對應設定；先驗證 lockfile 與審核流程，勿把自動更新 PR 視為相依內容已通過安全審查。

GitHub 官方公告

16｜Pydantic 2.14.3：Serialization 與相容性修正

版本日期 11/04；GitHub release 顯示 11/05

修正序列資料逐索引使用 include／exclude 時的平方級 serialization 時間，並改善 schema generation 與序列化效能。GraalPy wheel 也有調整：不再發布 3.11 wheel，改提供 3.13，並保留既有 3.12。

先做什麼： 用代表性的巢狀資料與大型 API response 跑 benchmark，核對驗證結果與 JSON Schema。效能改善需以實際資料量測，不能直接當作所有 API 都會加速。

v2.14.3 release

17｜Angular 22.2.5：Forms、Router 與 Resource

11/06 發布

rxResource 新增 debugName；自訂 FormValueControl 改善 updateOn: blur／submit，修正 required validator 對應與 router 的 focusReset 處理。圖片、影片的 src 為 null／undefined 時，也調整屬性移除行為。

先做什麼： Angular 22 專案應測試表單控制項、導航焦點及 resource 行為。舊 major 版本仍需依完整升級指南處理，不宜只為這次 patch 跨版升級。

v22.2.5 release

18｜Secret Scanning：新增偵測器、減少誤報

11/05 發布

GitHub 新增 Starlink API secret 偵測，SpaceX 加入合作夥伴計畫。Google Cloud Storage、AWS、Alibaba、OpenVSX、Pydantic Logfire、Tencent 等偵測器改善誤報過濾；這不代表涵蓋所有雲端憑證。

先做什麼： 確認適用的 Secret Scanning 與 Push Protection 設定，追查尚未處理的外洩告警。正式憑證仍應放在 secret manager，已外洩的金鑰需撤銷或輪替。

GitHub 官方公告

19｜Copilot Usage API：區分 BYOK 與企業自訂模型

11/03 公告

用量報表可分開辨識本機 BYOK、企業自訂模型與 Copilot 託管模型。本機 BYOK 資料依賴 client telemetry，停用遙測或 provider 不回報 token 時會低估；企業自訂模型為伺服器側統計，沒有相同限制。

先做什麼： 整合成本報表時標明資料缺口，避免把未回報用量當成零，也不要把不同付費來源混在一起比較。

GitHub 官方公告

20｜GPT-Image-2.6：SVG 與動畫 GIF

11/04 發布

gpt-image-2.6-sunburst、gpt-image-2.6-flare 支援圖片生成／編輯、可調整 complexity，以及 SVG、動畫 GIF 生成。受支援的 GPT-Image-2.5／2.6 模型也擴充 markup-guided editing。

先做什麼： 比較文字正確率、SVG 可編輯性、GIF 穩定性、生成時間與成本。將產物放進網頁前仍需檢查格式與內容，不直接信任生成的標記。

OpenAI API Changelog

後續追蹤

先處理有截止日的 GitHub Actions 政策與授權變更，再安排 SDK／CLI 相容性測試。Agent Registry、IP allowlist、AI code review 則適合先用小型測試專案驗證，不必一次全面導入。

本期另追蹤 FastAPI、Gemini API、MCP／A2A 與 RAG／evaluation，原週報未選出額外獨立消息；這不表示這些專案完全沒有更新。Cloud Run 的 Python 3.15 runtime 已於 11/02 進入 Preview，但不代表既有 Python 服務需要立即升級。

到期與生效日期

以下包含先前已公告的時程，並非全是本週新消息。日期狀態以 11/13 複核為準。

來源：Angular 支援時程、Claude 發布紀錄，以及第 01、02 則官方公告。

優先確認 APT 修補；使用 WordPress 或 SonicWall 的環境，應先處理已知遭利用的漏洞。以下是通用盤點建議，不代表任何個別系統已受影響或已完成修補。

1. APT：下載驗證繞過，可取得 root 權限

CVE-2026-109518｜11/04｜Canonical：High，CVSS 4.0 7.7

能操縱套件下載 HTTP 流量的攻擊者，可利用重新導向、下載重試與 hard link 處理缺陷，使 APT 安裝未驗證的套件。Debian 12、Ubuntu 22.04 起預設啟用下載重試；舊版也須檢查 Acquire::Retries 是否非零。

Ubuntu 20.04 及更舊版本的修補取得方式涉及 Ubuntu Pro／Legacy，須對照公告。先確認已安裝版本，再依維護流程更新。HTTPS 可保護這條下載路徑，但不應取代正式修補。本次未確認野外利用。

來源：Canonical 說明、USN-8996-1、Debian Tracker。

2. WordPress：更新期間的遠端程式碼執行

CVE-2026-119977｜11/03 列入 CISA KEV

WordPress 更新流程的競爭條件可能讓攻擊者在升級期間執行程式碼。7.1.4 已於 10/28 修補；本週的新進展是確認實際利用，而不是首次發布修補。

有部署 WordPress 時，確認已安裝 7.1.4 或所屬舊分支的對應安全更新，並檢查更新期間的異常存取。不要只確認主站，測試站與活動網站也應納入盤點。

來源：WordPress 7.1.4、加拿大網路安全中心 AV26-1117。

3. SonicWall：SSL VPN 驗證繞過

CVE-2026-19868｜11/06 列入 CISA KEV

這項 SonicOS SSL VPN 漏洞涉及驗證流程，原報告追蹤的是 SAML／MFA 繞過風險。加拿大網路安全中心確認 SonicWall 已表示漏洞遭到利用，並列出 7.3.4-7013、8.2.2-8015 的修補門檻。

應優先確認設備所屬分支、實際版本、VPN 對外暴露與異常登入紀錄。各機型及設定適用性仍以原廠公告為準；本次未能讀取原廠動態頁面的完整條件，因此不沿用原報告的 CVSS 數字。

來源：SonicWall SNWLID-2026-0014、加拿大網路安全中心 AV26-1133。

4. GCP／Linux Kernel：TCP 漏洞

CVE-2026-98432｜GCP-2026-078｜11/04

Linux IPv4 TCP 堆疊漏洞可能造成核心當機或容器逃逸。Google 列出 GKE Standard、Autopilot 受影響；網路攻擊需要連得到相關 TCP listener，容器內亦有本地觸發途徑。Google 此公告的產品風險分級為 Medium，不等同原報告引用的通用 CVSS 分數。

盤點時須區分作業系統、Kernel flavor 與實際運行核心，不能把 generic 核心狀態套到 linux-gcp。本次未重建 11/09 各發行版的歷史修補矩陣，請依官方現況核對，更新後確認新核心已生效。

來源：Google Cloud GCP-2026-078。

5. Ubuntu：Java 憑證信任庫未同步

USN-9001-1｜11/05

系統 CA bundle 移除憑證後，Java JKS keystore 可能未同步移除，讓 Java 程式繼續信任已撤除的 CA。更新會修正同步行為並重新同步信任庫；公告沒有獨立 CVE。

使用自訂 JKS、JDK 內建信任庫或容器映像時，須另外確認，不能只看 OS 套件更新。

來源：Ubuntu USN-9001-1。

6. Google Cloud SDK：Python／Java 憑證更新

GCP-2026-075｜11/02

eMudhra 憑證私鑰事件影響仍信任相關 CA 的應用程式。Google 表示其基礎設施未遭入侵，遙測未見相關工作負載利用證據。

公告要求檢查 certifi（至少 2026.10.19）、httplib2（0.32.1）、grpcio（1.84.1 或其他已修補分支），以及 Java google-api-client（2.9.2）。gRPC 使用的憑證集合不一定來自 OS，更新作業系統不代表應用程式已修好。完成依賴更新後重新建置、部署映像。

來源：Google Cloud GCP-2026-075。

7. NGINX：舊版 Ubuntu 補上安全更新

USN-8955-2｜11/05

本次把先前 NGINX 修補擴及 Ubuntu 20.04、18.04、16.04、14.04，並修正 CVE-2026-42533。特定 regex、capture variable、map 或 alias／rewrite 組合可能造成當機或程式碼執行；僅看到 alias 不足以判定符合觸發條件。

Ubuntu 20.04 的公告修補版本為 1.18.0-0ubuntu1.7+esm4，其他舊版須對照各自套件表及 Pro／ESM 資格。Ubuntu 22.04 以上則查 USN-8955-1；Debian 必須另查其 Tracker，不能套用 Ubuntu 結論。本次未重新確認 Debian 12 的即時修補狀態。

來源：Ubuntu USN-8955-2。

8. Chrome 157：瀏覽器安全更新

11/03 Stable 發布

公告版本為 Linux 157.0.8103.38，Windows／macOS 157.0.8103.38/.39，包含記憶體安全等問題，且有 Critical 項目。應更新瀏覽器並重新啟動，確認新版本已實際載入。

11/13 校訂： 原週報寫 213 項修補，部分搜尋摘要仍如此顯示，但官方公告正文目前寫 212 項，本文以正文為準。原週報只舉低風險 CVE，不能代表整次更新的嚴重程度。本次未確認這批項目的野外利用狀態。

來源：Chrome Releases。

9. AWS Serverless MCP Server：路徑穿越

CVE-2026-116635｜11/02

能影響 MCP agent 輸入的攻擊者，在特定條件下可讀取部署狀態目錄以外的 JSON；若啟用寫入，也可能建立或覆寫目錄外的 JSON。

awslabs.aws-serverless-mcp-server 低於 0.2.1 受影響，0.2.1 已修補。AWS 未提供替代緩解措施，應更新套件，分叉版本也須帶入修正。公告未列 CVSS，本次未確認實際利用。

來源：AWS 2026-164。

10. AWS EKS：NetworkPolicy 隔離繞過

CVE-2026-122266｜11/04

共享 eBPF 連線狀態隔離不足，可能讓具相鄰環境存取能力的已驗證使用者繞過同節點其他 Pod 的 ingress NetworkPolicy。

AWS 表示沒有替代緩解措施。使用 EKS NetworkPolicy 時應確認元件版本及更新後的網路隔離行為。公告未列 CVSS，本次未確認實際利用。

來源：AWS 2026-170。

11. AWS Babelfish：TDS 記憶體安全漏洞

CVE-2026-119923、CVE-2026-119924｜11/06

前者涉及 TDS 握手，可由未驗證遠端攻擊者影響資料庫程序；後者涉及 TDS RPC，已驗證攻擊者可能讀取鄰近記憶體或造成服務中斷。

Babelfish for PostgreSQL extension 的修補版包含 4.10、5.6、6.1。Aurora 的修補門檻依分支不同，應對照公告中的 Aurora／Babelfish 版本配對，並完成待處理維護，不能直接套用 extension 版號。更新前可先把 TDS 連接埠來源限制為可信來源。本次未確認實際利用。

來源：AWS 2026-166。

12. Python：Pillow、Twisted、Tornado

三項更新的適用情境不同，不應只用「Python 有漏洞」概括。

APT 安裝的 Python 套件與 pip、Poetry、uv 的虛擬環境要分開盤點。更新後除了版本檢查，也應測試影像處理、郵件及靜態檔案功能。

來源：Pillow、Twisted、Tornado。

13. Debian：APT、zlib 與 Kernel 公告

上述 DSA 的版本表主要針對 Debian 13（Trixie）。Debian 12（Bookworm）應另看 Tracker／LTS 公告，不能因為 DSA 已發布就認定同樣修好。

來源：APT 公告、zlib 公告、Linux 公告。

14. PostgreSQL 14：支援期限到期

這不是新漏洞，而是版本維護期限。官方版本政策列出的 PostgreSQL 14 最終發行日為 2026/11/12。

11/13 更新： 官方目前列出 14.25，因此原報告「最後版本為 14.24」的說法不再適用。盤點仍使用 14 的資料庫，確認升級或額外維護方案；最後一次小版本更新不能取代後續主版本遷移。大版本升級需先測試資料遷移、擴充套件與回復流程。

來源：PostgreSQL 版本政策。

其他平台追蹤

以下保留 11/09 原報告的追蹤範圍。原檢索未取得足夠證據列出該週新增重大事件；這不是「沒有漏洞」的保證，11/13 的補稿也沒有重跑所有平台的完整歷史調查。

檢查順序

1. 確認是否使用 WordPress、SonicWall，優先處理已知遭利用項目。
2. 檢查 APT、NGINX、Kernel 的完整套件版本與適用設定。
3. 分別檢查 OS、Java、Python 與容器的憑證信任庫及依賴。
4. 盤點 EKS、MCP Server、Babelfish，套用對應分支的更新。
5. 更新瀏覽器，處理 PostgreSQL 14 的版本遷移。

以下只讀取本機狀態，不會安裝更新：

1
2
3

apt-cache policy apt nginx ca-certificates ca-certificates-java
apt-config dump | grep -i 'Acquire::Retries'
uname -r

套件版本、執行中的版本及設定條件都要符合，才可判定修補生效。本文未檢查任何個別主機，也未保留私人環境設定。

▶ 什麼是來源/媒介 ?

簡單來說就是判斷這個流量從哪邊來? 是從 Google 搜尋引擎進入網站還是從 FB 粉專進入網站。
以下為 GA3 & GA4 的來源/媒介報表路徑

• GA3 : 獲客 > 所有流量 > 來源/媒介
• GA4 : 獲客 > 流量開發 : 工作階段預設管道分組 (如下圖)
  

▶ GA3 vs. GA4 BigQuery 來源/媒介欄位比較表

GA3 時代，從 BigQuery 中提取來源/媒介數據時，會使用欄位「trafficSource.source」&「trafficSource.medium」，這是沒有錯的!這兩個欄位代表的是每次進站的渠道。
<附上 GA3 匯出 BigQuery 的結構定義>

當看到 GA4 匯出到 BigQuery 的 Dataset 中看到「traffic_source.source」&「traffic_source.medium」時，心中是不是無比喜悅，就是他惹 :100:

但是! 現在我們來看一下 Google 的官方文件說明(附上截圖&文件)，
補充:這兩個欄位會對應到 GA4 維度為「最初招攬到使用者的來源/媒介」

• traffic_source.source: 初次招攬到使用者的聯播網名稱。
• traffic_source.medium: 初次招攬到使用者的媒介名稱。

「初次招攬」指的是第一次進到網站的使用者是從哪個渠道進入網站，是 FB 廣告還是 Google 自然搜尋等等。
舉例來說 :
小明點了 Google 廣告，第一次進到網站中，那欄位值會如下

• traffic_source.source: google
• traffic_source.medium: cpc

那小明隔天從 LINE 官方帳號進入網站，那欄位值是什麼?
值還是一樣的 ! 因為「traffic_source.source 和 traffic_source.medium 這兩個欄位就是這兩個欄位僅記錄用戶首次訪問網站時的來源媒介

• traffic_source.source: google
• traffic_source.medium: cpc

▶那第2次的來源媒介要怎麼取得?

GA4 的數據模型是由事件組成，所以每個 event_name 對應一個資料列。
event_name = page_view 指的就是每一次的網站瀏覽，所以第二次進站的來源媒介，會出現在事件名為 page_view 的資料列中，包含 source 和 medium 參數。

▶2種情境與對應值，分享給大家

情境1 :小明從 Google 自然搜尋第1次進站到首頁，點了站內 UTM(Urchin Tracking Module) 到活動頁

下表為 BQ 中的資料列示意

情境2 : 延續情境1，隔天小明點了 FB 粉專的貼文進入了網站商品頁，粉專貼文的連結有帶 UTM 為 Facebook / post

下表為 BQ 中的資料列示意

結論 : traffic_source 欄位僅記錄用戶首次訪問網站時的來源媒介，不會因未來用戶進入網站的渠道而改變其值。

附上查詢 SQL

1
2

SELECT event_date,event_name, event_params, traffic_source.source, traffic_source.medium
FROM `你的工作表名稱`

▶ 什麼是項目範圍自訂維度(item scope) ?
項目範圍的維度，是指專門用來追蹤 GA4 電子商務事件中商品的資訊，例如 : 商品名稱、商品id、顏色、尺寸、重量等等。
在項目範圍的維度中，有分 GA4 預設維度 & 最近才公布的自訂維度。
舉例來說 :
GA4 預設維度 : 商品名稱(item_name)、商品編號(item_id)、商品價格(price)等等。官方文件
自訂維度 : 用來補足 GA4 預設維度中沒有的維度，由自己定義，例如 : 課程長度、售票種類、商品關鍵字等等。
數量限制 : 免費版資源 : 10個 / 付費版資源 : 25個

▶ 項目範圍自訂維度(item scope)情境舉例
以這一個商品舉例，右邊 items 陣列中的參數(item_name、item_id、price 等)都屬於 GA4 的預設項目範圍維度。

若想多追蹤杯子的容量，GA4 預設的項目範圍維度又沒有提供對應參數，這時候，就可以自訂一個項目範圍的自訂維度，Datalayer 調整後如下圖，新增的參數一定要放在 items 陣列中。

▶ 項目範圍自訂維度(item scope)要如何在 GA4 中設定 ?
確認有把自訂的參數送到 GA4 後，接下來就是要在 GA4 中設定自訂維度，
設定路徑 : 管理(左下角齒輪) > 自訂定義 > 建立自訂維度(藍底按鈕) > 範圍選 : 項目 > 按下儲存
可參考以下圖片，依序設定。

(下圖)記得範圍要選「項目」，項目參數需要填寫您在網站中傳送的參數名稱，以本次範例為例，則是填入 capacity (並非照填寫 capacity) 。

(下圖)儲存後，會出現範圍為「項目」的自訂維度。

▶ 項目範圍自訂維度(item scope)在 GA4 探索報表中的呈現
目前還無法在預設報表中，透過次要維度或是利用自訂報表功能拉取項目範圍維度，所以設定完的項目範圍自訂維度無法呈現在電子商務報表中，只能在探索報表使用，這部分較可惜，希望未來能更新上去。

• 補充提醒，電子商務相關的維度都只能搭配使用部分指標，所以建議先拉取項目範圍的維度後，再選擇指標(無法使用的指標會被反灰)。

此外Looker Studio 中也無法拉取項目範圍的自訂維度，以上的限制待未來更新後，再分享給大家~

範例連結：https://codepen.io/andyhung0723/pen/YzeOovW

問題

假設我有一個 table，若我想將它的表頭凍結在最上方不動，可以使用position: sticky：

1
2
3
4

.table-sticky .th {
  position: sticky;
  top: 0;
}

若在小畫面時想要此 table 不要撐開整體寬度，一般會在外層使用overflow-x: auto來讓 X 軸產生 scroll bar：

1
2
3

.table-sticky-container {
  overflow-x: auto;
}

此時就會發現原本position: sticky的凍結效果卻失效了。

原因

經測試發現只要position: sticky上所有階層的父元素只要有一個的overflow值是visible以外的其他值，就會導致失效。

解法

目前單純使用 CSS 貌似沒有解法，因此我使用 JavaScript 的 scroll 事件來動態 transform 表頭的位置來解決，程式碼如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

window.addEventListener('scroll', function(event) {
  var scrollTop = window.pageYOffset || document.documentElement.scrollTop || document.body.scrollTop || 0;
  var stickyTables = document.querySelectorAll('.table-sticky');
  for(var i = 0 ; i < stickyTables.length ; i++) {
    var thead = stickyTables[i].querySelector('thead');
    var offsetTop = stickyTables[i].offsetTop;
    var offsetHeight = stickyTables[i].offsetHeight - thead.offsetHeight;
    var transformY = getTranslateY(thead);
    if(scrollTop >= offsetTop && scrollTop <= offsetTop + offsetHeight) {
      transformY = scrollTop - offsetTop;
    }else if(scrollTop < offsetTop){
      transformY = 0;
    }
    thead.style.transform = 'translateY('+ transformY +'px)';
  } 
});

function getTranslateY(element) {
  var style = window.getComputedStyle(element);
  var matrix = new WebKitCSSMatrix(style.transform);
  return matrix.m42;
}

範例連結：https://stackblitz.com/edit/angular-ivy-bmpsfk

問題

假設有一個按鈕，點擊之後可依狀態顯示不同的 Component。

1
2
3
4
5
6
7
8

<div class="container">
  <app-first *ngIf="visibleComponent === 'first'; else second"></app-first>
  <ng-template #second>
    <app-second></app-second>
  </ng-template>
</div>

<button (click)="switch()">switch</button>

在 first component 中我們嘗試取得該元素的offsetWidth。

1

<div #content>first component</div>

1
2
3
4
5

...
ngAfterViewInit() {
  console.log('content width: ', this.content.nativeElement.offsetWidth);
}
...

結果在當由 second 切換到 first 時，取得的 offsetWidth 為624px，但實際應為639px，少了15px。

原因

經過測試後發現當有載入BrowserAnimationsModule才會發生此問題，且是 second component 中有 scroll bar 的原因，導致在取得 offsetWidth 時少了 15px。

但明明我是在 first component 中取 offsetWidth 阿？怎麼會吃到 scroll bar？

原來是在 ngAfterViewInit 執行的當下子 Component 的畫面會比父 Component 還早運算，我們 ngIf 的條件是寫在父 Component 進行判斷，所以當下吃到的父層寬度還會保留在切換到另一個 Component 之前。

子 Component 的 ngAfterViewInit 也會比父 Component 的同一個事件還早執行。

由於 second component 多了 scroll bar，且在載入BrowserAnimationsModule時 scroll bar 會被算成 15px 的空間，所以在取得 offsetWidth 會少了 scroll bar 佔去的寬度。

解法

由於是執行順序的問題，所以最簡單的解法就是透過setTimeout將取得 offsetWidth 的動作強制移動置 event loop 的最後執行。

1
2
3
4
5
6
7
8
9
10

ngAfterViewInit() {
  console.log('content width: ', this.content.nativeElement.offsetWidth);

  setTimeout(() => {
    console.log(
      'content width after: ',
      this.content.nativeElement.offsetWidth
    );
  });
}

執行結果

目前只有嘗試到這個方式，若有找到更好的寫法會再更新。

為了解決這個問題，Angular 有針對 Module 提供 Lazy Loading 的功能，簡單來說就是當需要此 Module 的時候再進行載入，如此就不會影響到整個應用程式的效能。

實現方式

透過 Angular Router 中內建的功能即可實現，步驟如下：

1. 修改app-routing.module.ts

1
2
3
4
5
6

const routes: Routes = [
  {
    path: 'customers',
    loadChildren: () => import('./customers/customers.module').then(m => m.CustomersModule)
  }
];

利用loadChildren這個屬性，我們就可以透過 import 將我們想要 lazy loading 的 Module，在應用程式觸發到path中定義的路由(在這個例子中就是/customers)的時候將 CustomersModule 進行載入。

2. 修改customers.module.ts

1
2
3
4
5
6
7
8
9
10
11

import { CustomersRoutingModule } from './customers-routing.module';

@NgModule({
  declarations: [
    CustomersComponent
  ],
  imports: [
    CommonModule,
    CustomersRoutingModule
  ]
})

額外新增customers-routing.module.ts，並新增到 CustomersModule 的 imports 中，我們會將關於此 Module 下 Router 的設定拆出來放在這個檔案中。

3. 新增customers-routing.module.ts

1
2
3
4
5
6
7
8
9
10
11
12

const routes: Routes = [
  { 
    path: 'info', 
    component: CustomersComponent 
  }
];

@NgModule({
  imports: [RouterModule.forChild(routes)],
  exports: [RouterModule]
})
export class CustomersRoutingModule { }

這邊我們就可以定義在子路徑下要載入哪個 Component，最終的路徑會是原本app-routing.module.ts中定義的path加上這邊定義的path，以上例來說就會是在/customers/info下讀取到 CustomersComponent。這邊要注意需要用forChild來定義子路由。

透過指令建立

如果我們在一開始就決定要使用 lazy loading 的方式載入 Module，也可以選擇用以下指令直接建立好上述的元件：

1

ng generate module customers --route customers --module app.module

實驗

我們可以在customers.components.ts中加上console.log來實驗是否有 lazy loading

1
2
3
4
5
6
7
8

export class CustomersComponent implements OnInit {

  constructor() { }

  ngOnInit() {
    console.log("Customers Component Init");
  }
}

• 讀取 http://localhost:4200
  

• 讀取 http://localhost:4200/customers
  

注意事項

• 如果 Module 需要 lazy loading，需注意app.module.ts裡面不可以 import 到這個 Module，否則還是會在應用程式啟動時就載入。

也可以將有相同特性的功能拆出來，組合成不同的模組，各個模組間依程式架構相互引用，組合成 Angular 應用程式。模組中可以透過設定的方式，定義此模組中包含的 components、directives、pipes 等，以及其他與模組相關的屬性，以下我們就來研究一下 Angular Module 的使用方式以及使用情境。

組成

1
2
3
4
5
6
7
8
9
10

@NgModule({
  declarations: [
    AppComponent,
  ],
  imports: [
    BrowserModule,
  ],
  providers: [],
  bootstrap: [AppComponent]
})

定義模組的檔案中會包含@NgModule，用來定義模組的設定。主要包含以下幾個屬性：

declarations

用來宣告此模組中包含的 components、directives、pipes。

1
2
3
4
5

declarations: [
  UserComponent,
  CustomPipe,
  FileDirective
],;

• 若使用ng generate 指令來產生物件，Angular CLI 會自動幫你把物件加入 declarations 中。

imports

想要額外載入的 module，載入後就可以使用該 module 中 exports 的物件。

1
2
3
4

imports: [
  BrowserModule,
  UserModule
],

• 如上例，只要 import UserModule，模組內就可以使用 UserModule 中 export 的所有物件。
• 根模組必須要 import BrowserModule。
• 其他模組必須要 import CommonModule。
• 只要是用 CLI 建立的，上述兩項都會自動 import。

exports

要匯出給其他模組使用的物件。

1
2
3
4
5
6
7
8

declarations: [
  UserComponent,
  CustomPipe,
  FileDirective
],;
exports: [
  UserComponent
],

• 要 export 的物件必須存在於 declarations 或 import 的 Module 中才可以。
• 上例 export 的只有 UserComponent，因此引入此 module 的模組只可使用 UserComponent。

providers

宣告可以依賴注入的 service，整個應用程式都可以使用到此處宣告的 service。

1
2
3

providers: [
  UserService
],

關於 providers 會再整理一篇文章進行探討。

bootstrap

1

bootstrap: [AppComponent],

定義根元件，作為應用程式啟動後預設讀取的元件，只有根模組需要定義此屬性，一般不太需要更動。

使用情境

Module 用法除了最基本會有的根模組(Root Module) 外，常見的還有以下兩種用法：

Feature Module

其實就是最常見、第一個會想到使用 Module 的情境。將應用程式中你認為可以額外拆出來撰寫成一個功能的程式片段，拆出來成為一個 Module，就會稱它為Feature Module。

例如假設今天要實作一個網頁聊天室，聊天室可以傳送的訊息種類分為文字、檔案、圖片、貼圖等，我們就可以把傳送的**「訊息」** 拆一個 MessageModule，裡面包含 TextComponent、FileComponent、ImageComponent … 與其他串接的 Service 等。

Shared Module

在 Angular 中常常會遇到很多物件(component、directive、pipe)一直被重複使用，此時為了不讓這些物件散落各地，還要讓 Module 一直引用來引用去，通常可以建立一個Shared Module來統一管理這些物件，要使用這些物件的 Module 只需要匯入一個Shared Module就可以了。

1
2
3
4
5
6
7
8
9
10
11
12
13

@NgModule({
  declarations: [
    TableComponent, 
    PagerComponent, 
    PaginationComponent
  ],
  exports: [
    TableComponent, 
    PagerComponent, 
    PaginationComponent
  ],
})
export class SharedModule {}

• 如上例，其他模組只需要 import SharedModule 就可以使用裡面的所有物件。