CẨM NANG TOÀN DIỆN VỀ KIẾN TRÚC VÀ IMPLEMENTATION "QUẢN LÝ TÀI KHOẢN GOOGLE" (PROFILE MANAGEMENT)

Bản cập nhật kỹ thuật hệ thống - Master Documentation. Quy mô: Lớn.

Thư mục Frontend: admin/src/views/profile-management/
Thư mục Backend: api/internal/profiles/
Thư mục Cơ sở dữ liệu: Bảng MySQL (profiles nếu dùng MySQL) hoặc Collection MongoDB. Các tính năng chính bao gồm CRUD, Phân công Server, Mở khóa Captcha, Quản lý tiến trình (Sessions) & Tính toán thời gian vòng đời (Cooldown/Age).

I. TẦNG NHÌN TỔNG QUAN VÀ SỨ MỆNH MODULE

Quản Lý Tài Khoản (Hay chính xác hơn là Quản lý File Cấu hình Trình Duyệt Google Chrome Profile) là trung tâm năng lượng của công cụ Boot Traffic. Một tài khoản Google sống sốt, được "Nuôi" qua thời gian dài để củng cố độ uy tín (Trust) là chìa khóa để thuật toán Google Search / Google Ads tính view hợp lệ.

Các thử thách đặt ra khi phát triển module này:

Dữ liệu phức tạp: Profile không chỉ chứa email, password mà còn là user-agent, proxy, geo-location, độ phân giải màn hình, hệ điều hành. Nói cách khác Profile là một trình duyệt Ảo.

Phiên đăng nhập (Session): Phải theo dõi tài khoản có đang chạy dở task nào không, có bị chặn (Blocked) không thì mới thu hồi quyền về Kho.

Tuổi thọ sử dụng (Cooldown/Age): Dùng xong phải cho tài khoản nghỉ (Cooldown) để không bị khóa (Ban).

Volume Khủng Khiếp: Quản lý hàng trăm ngàn Profile, import cực lẹ (Bulk Add).

Để giải quyết vấn đề, hệ thống phân chia rõ ràng trách nhiệm ở Frontend thành các Composables độc lập kết hợp Modal, và ở Backend chia nhỏ Handlers theo nhóm nhiệm vụ.

II. KIẾN TRÚC MÃ NGUỒN FRONTEND (VUE 3 - COMPOSITION API)

Màn hình chính được cấu trúc ở file trung tâm UnifiedProfileManagement.vue. Từ "Unified" ở đây mang ý nghĩa Giao Diện Đồng Nhất:

Sức mạnh của UnifiedProfileManagement.vue nằm ở việc code Component này không chứa logic dài dòng. Nó tuân thủ mẫu thiết kế Controller (Smart/Dumb Components). Nó đóng vai trò "Trạm Trung Chuyển State" (Props Down, Events Up):

Bất kỳ Logic nào liên quan đến Modal đều đẩy vào operations, Logic liên quan đến Table đổ vào useProfileTable.

1. Phép Màu Quản Lý Store Bằng Composition Đa Tầng Của Pinia

Trong Vue hiện đại, File Store thường chứa hàng ngàn dòng. Các kỹ sư của WinAd thay vì nhồi tất cả vào 1 file useStore.ts, họ đã cắt vụn nó thành 3 file Actions độc lập:

Đường dẫn: admin/src/views/profile-management/profiles/stores/

Đây là đỉnh cao của Store Modularity. Khi có Bug về Add Profile, Dev chỉ cần vào useProfileCrudActions.ts. Khi có Bug về Load phân trang, vào useProfilePaginationActions.ts. Điều này giúp quản lý 10.000 dòng code Vue Frontend Store mà không bị rối rắm.

2. Định Nghĩa Data Type Profile Khổng Lồ

Thực thể Profile là một trong những Interface "bự" nhất trong codebase:

III. THUẬT TOÁN ĐỒNG HỒ ĐẾM NGƯỢC THỜI GIAN THỰC (`useCountdownTimer`)

Khi một tài khoản chạy xong Task lúc 08:00, và thuật toán cho nó Cooldown 2 tiếng. Trong vòng bảng User Management, Status của nó sẽ là Cooldown (Chờ làm mát). Web App cần hiện thị cho người dùng biết "Còn bao nhiêu Giờ Phút Giây thì tài khoản này được giải phóng".

1. Kiến trúc Timer của Frontend

Tại composables/useCountdownTimer.ts, có một trick Force Vue Render rất thông minh:

Sức mạnh thực sự nằm ở Component Bảng ProfileTable.vue sử dụng trigger này:

Kết quả ta nhận được là hơn 1.000 dòng dữ liệu Profile, trong đó có 200 dòng đang đếm ngược nhảy lùi 01:59:59 -> 01:59:58 theo thời gian thực mà Ứng Dụng KHÔNG HỀ BỊ LAG! Kỹ Thuật Functional Render h() kết hợp Trigger này rất tốn chất xám để nghĩ ra!

IV. QUÉT KHỐI BULK ADD (THÊM TÀI KHOẢN HÀNG LOẠT) VÀ CẠM BẪY

Về mặt Giao diện, component BulkAddAccountsModal.vue đóng vai trò Parsing.
Admin quản lý thường có 1 file Text hoặc Excel, lưu thông tin tài khoản: Email | Password | Recovery.
Hoặc đôi khi lưu cả Proxy|Server|Email.

Bên Frontend chỉ lo việc Tách chuỗi (Split theo dấu phẩy, dấu gạch đứng |), biến chuỗi thành Mảng JSON Array hàng nghìn Object.

Rủi ro nguy hiểm là Payload POST /api/profiles/bulk quá lớn, chứa hàng nghìn Account. Nếu Backend thực thi lệnh INSERT từng hàng trong vòng lặp for vào Database, mất tầm 5 phút, Cổng API sập Timeout Error.

Cách Backend ứng biến sẽ được nói chi tiết phần sau.

V. CẠM BẪY N+1 DATABASE VÀ QUY LUẬT BULK ADD Ở BACKEND (`profile_crud_handlers.go`)

Để tiếp nối hành trình Upload hàng 100 Account một lúc, Backend thiết lập một chốt chặn rất cứng tại HTTP Handler của Golang Fiber:

Việc lặp mảng để gọi lệnh CreateProfile(InsertOne ở DB) tạo ra tình huống O(n) Network Call xuống MongoDB. Nhưng nhờ việc khoá trần (Cap Limit = 100), Thời gian response của Bulk Update vẫn an toàn dưới ngưỡng 3-5 giây. Frontend khi nhận được mảng errors sẽ hiển thị màu Đỏ cho những Account đã tồn tại (Duplicate) và Xanh cho những tài khoản Insert thành công. User Experience hoàn hảo thay vì ném ra 500 Internal Server Error vỡ cả mảng.

VI. QUY LUẬT GIAO VIỆC (TASK DISPATCHING) BẢO VỆ TÀI KHOẢN KHÔNG BỊ BAN

Rất ít khi người ta cấp phát Profile ra cho Tool cắm ngẫu nhiên. Tài khoản Google có rủi ro bị khóa vĩnh viễn (Banned) nếu nó đăng nhập và search quá số lần một ngày (Vượt Limit).

Mở file api/internal/profiles/service/profile_crud.go có một hàm cốt tử định đoạt con bot nào được chạy:
GetRandomAvailableProfile()

Nhìn sâu vào hàm filterProfilesByDailyLimit, hệ thống duyệt qua Tôn giáo MongoDB:

Nhận xét Kỹ Thuật:
Hàm đếm số Job (CountDocuments) lọt trong vòng lặp VÀ CÀY TRỰC TIẾP lên DB (Vấn đề N+1 Query). Trả giá cho việc này là Query Cost có thể rất đắt. Để tối ưu trong tương lai, WinAd nên đổi sang dùng hàm Aggregate ($group) của MongoDB thay vì Loop Count.
Tuy nhiên, Với việc CountDocuments đã được Index trường Data created_at và assigned_profile_id, Tốc độ vẫn mượt mà cho 1 số lượng Server Node vừa phải.

VII. CHIẾN BINH ÂM THẦM: BULK ACTIONS VÀ TRẠNG THÁI PROFILE

Vòng đời của 1 profile ở Table Grid thay đổi không ngừng.
Tại sao Vue Store lại có hàm BulkUpdateProfiles? Bởi vì đôi khi 50 profile bị chết IP Proxy, người quản lý muốn ngắt cắm hàng loạt.

Ở phương thức này, con số cho phép là 1000 Rows. Repository BulkUpdateProfiles sẽ chạy câu lệnh MongoDB $updateMany: { $in: [ID_1, ID_2] }, cập nhật cái vèo toàn bộ 1000 row chuyển status thành deactivate. Tốc độ chỉ dưới 50ms. Cực kì lợi hại khi kết hợp Data Bulk Selection ở Frontend useBulkSelection.ts.

VIII. KIẾN TRÚC PHIÊN LÀM VIỆC ĐA NHIỆM (PROFILE SESSIONS)

Một tài khoản Google trong "Traffic Tools" không bao giờ chỉ chạy 1 Tab. Thông thường Worker Node (Máy chủ cấp dưới cắm Extension) sẽ mở tài khoản đó ra thành một Session (Phiên làm việc).

Database Schema liên quan:
Bảng profile_sessions (Cấu trúc BSON MongoDB Collection).

1. Tại sao cần tách Bảng Session?

Nếu ta lưu Trạng thái hoạt động gộp thẳng vào Bảng Profile, ta sẽ đối mặt với "Deadlock" (Khóa ghi). Vì mỗi giây, Worker sẽ bắn Ping (Session Life Heartbeat) về master 1 lần. Update thẳng vào mảng Profile.sessions sẽ làm hỏng dữ liệu của Master. Việc Tách mảng profile_sessions giúp Backend ghi đè không sợ xung đột.

2. Định nghĩa DTO `CreateProfileSessionRequest`

Trong file profile_sessions.go, đoạn code sau tự động hóa cấu hình ngày giờ chết của Session:

Về mặt Frontend, ProfileDetailModal.vue chịu trách nhiệm gọi GET Array và vẽ một Component UI <n-card> liệt kê tất cả trình duyệt Chrome đang cắm vào tài khoản này (Hiển thị các tab IP, Trạng thái Active/Die).

Nếu một Tool Cào cố gắng sử dụng Profile X nhưng bị văng ra vì Sai mật khẩu hoặc Yêu cầu xác minh 2 bước. Nó sẽ báo lỗi về Master. Nếu báo nhiều lần thì sao?

File api/internal/profiles/service/profile_operations.go chứa Cây Logic phán xử (Penance Logic):

Đây là Cốt lõi của Hệ điều hành AI Phân Tán:

Front-End Admin Quản Trị chỉ việc Cung Cấp Data tĩnh.

Node Cào Web (Puppeteer/Playwright) sẽ thực thi.

BackEnd (Golang Server) đóng vai trò Thẩm Phán. Quá 3 lần sai mật khẩu chặn đăng nhập tự thiết lập thuộc tính is_deactivated = true cho Profile này. Node Cào Web tự vứt Profile đi và Roll Random Profile Mới. Không có sự tham gia của con người!

X. CÂY CẤU TRÚC MODAL COMPOSABLE: `PROFILETABLE.VUE`

Bảng Table Profile của View UnifiedProfileManagement.vue là một trong những khối Component đồ sộ với Hàng chục nút Bấm Edit, Check, Watch Session, View Task.

Và ở Template HTML ProfileTable.vue:

Sức mạnh thực sự là hàm createColumns không nạp code chết HTML. Nó nạp bằng h() Vue Render Function trong Typescript để tạo ra JSX-like Elements.
Điều này mang lại một khả năng bứt phá tốc độ Render: n-data-table của NaiveUI không phải Compile HTML Template hàng ngàn lần.

Với lượng Data cột như user_token, profile_id, proxy_id, Tốc độ Paint Frame của Browser nhảy từ 30fps lên 120fps (Cực kỳ xịn xò với Native JSX Rendering Arrays).

XI. NGHIỆP VỤ LIÊN HOÀN (REPORT TASKS BY DOMAIN) TRONG PROFILE

Quản lý một Profile không chỉ là xem nó chứa Password gì. Mà cấp Admin phải có khả năng Track xem Profile Google này ĐÃ TỪNG DÙNG ĐỂ SEARCH KEYWORD NÀO trong ngày. Tránh tình trạng Google AI theo vết 1 profile Search Cùng 1 Keyword Trả thù Mức độ cao.

Endpoints Mapping tại API handler/profile_crud_handlers.go:

Với Logic ở Cấp Repository, Backend Query liên kết bảng profiles và bảng report_tasks thông qua từ khoá assigned_profile_id == profileID. Việc phân mảnh dữ liệu GetProfileReportTasksByDomain giúp Quản trị viên chỉ cần Nhấp Nút (Icon Mắt) tại Bảng Profile -> Hiện modal Load ngay lập tức danh sách hàng trăm dòng Job search nó vừa search được cho Domain abc.com. Không cần phải chạy File Excel ở trang Report Center Cồng Kềnh!

XII. NGHỆ THUẬT LỌC VÀ TÌM KIẾM (`PROFILEFILTERS.VUE`) KHÔNG CẦN NÚT SEARCH

Nếu quan sát Component ProfileFilters.vue, nó không hoạt động theo kiểu "Chọn Xong Phải Bấm Nút OK Mới Lọc Mảng". Mọi Filter từ Status (Active/Cooldown) đến Server Host (VietNam_VPS_01, VietNam_VPS_02) đều được tự động Bind v-model kết nối Event Driven.

Ở đoạn cấu trúc logic dưới kịch bản TypeScript:

Sử dụng Computed Properties với Get và Set (2-way Binding Pattern) để emit Data ngược về thằng Bố UnifiedProfileManagement.vue. Nhờ vậy, UnifiedProfileManagement.vue sẽ gọi fetchProfiles() ngay lập tức mỗi khi Giá trị statusFilter thay đổi, hệ thống sẽ chớp tắt nhẹ cái Table Loading và Data mới ùa ra. Cảm giác tương tác thời gian thực tuyệt vời!

Phần hay nhất là Thẻ Gắn Nhãn Tag (hasActiveFilters):
Nếu Admin vô tình chọn Lọc Ngày Tháng Năm, hệ thống sẽ hiện ra thẻ màu NTag xanh lơ:
Bộ lọc đang áp dụng: [Trạng thái: Hoạt Động] [Máy chủ: Server HN]
Mọi thẻ đều có nút huỷ (X / Closable), người tạo Component đã lường trước UX chống lạc Data cực kỳ tỉ mỉ.

XIII. RÁC TRÌNH DUYỆT: THU DỌN CHIẾN TRƯỜNG BẰNG `CLEANUP_HANDLERS.GO`

Trình duyệt của bot sẽ tạo Local Storage, Cookies, SQLite History. Trong Database của Master, chúng ta gọi nó là ProfileSessions.
Thử tưởng tượng 10,000 Profile Google Mở 5 tab mỗi ngày. Sau 1 tháng ta sẽ có 1.5 triệu Dòng JSON Rác (Đã hết hạn ExpireAt).

Backend cung cấp 1 API vệ sinh tự động để dọn sạch Database, giúp MongoDB không bị đầy Ổ cứng (Disk Space).

Ở Service profile_cleanup.go, Hàm Lớn Nhất là ComprehensiveCleanup:

Đây là 1 API CronJob-friendly. Bằng cách gọi GET /api/profiles/admin/cleanup chạy hàng đêm bằng Node Schedule Master, Hệ thống sẽ bảo vệ được Data Space và Tốc độ Index Của Database Ổn Định Nhất Mức Có Thể.

XIV. ĐO TAI BIẾN TÀI KHOẢN TỪ XA (`TestProfileConnection`)

Làm sao biết Tài khoản Google này có Đăng nhập Thành Công bên Server Nước Ngoài không? Thay vì RDP (Remote Desktop) vào máy chủ đó, WinAd tích hợp bộ dò thông hành Ping Test qua Component Backend.

Đây là 1 API Helper. Nó chưa ping trực tiếp Google Login (Do điều này cần Playwright), nhưng nó xác thực Cấu hình Proxy và Profile Node trên MongoDB Server đang sống. Nếu báo Xanh, Admin mới tiếp tục Cấp Lệnh Chạy Cày View.

XV. KĨ THUẬT RÀNG BUỘC (CONDITIONAL RENDERING) Ở `PROFILE_EDIT_MODAL.VUE`

File Component ProfileEditModal.vue có tới gần 300 dòng mã nguồn vì nó chứa một cái Form Siêu Khổng Lồ để chỉnh sửa 1 Account Google.
Điều đặc sắc nhất của Form này là nó Tự Động Biến Đổi Layout dựa theo used_for (Loại Ứng Dụng của Tab Profile):

Bởi vì Google đã vô hiệu hóa "Mật khẩu kém an toàn", các tài khoản dùng để Push Report (SMTP Mail) buộc phải khai báo biến AppPassword. Component đã tinh tế dùng v-if để ẩn field này đi nếu Profile đó chỉ dùng để Click Quảng Cáo (Search Based), giúp Frontend không bị rối.

Đồng bộ hóa biến Props (`watch`)

Trong Vue 3, Props truyền từ Cha (UnifiedProfileManagement.vue) xuống Modal con vốn dĩ là Read-Only (Chỉ Đọc). Làm sao để Edit Form mà không làm rách Object của Cây cha?

Thay vì chọc trực tiếp vào State của Pinia (Gây lỗi Mutation Error khi đang gõ), Coder đã clone ra localProfile. Chỉ khi user bấm NButton @click="handleSave", nó mới bắn Ngược bản Local này lên cho thẻ Bố lưu vào Store. Pattern Modal chuẩn chỉnh!

XVI. SỰ "HOANG TƯỞNG" BẢO MẬT (HARDWARE BAN EVASION)

Nếu bạn thắc mắc tại sao hệ thống cần lưu quá nhiều trường thông tin phần cứng như browser_type, operating_system, screen_resolution, user_agent, v.v

profiles MongoDB chứa:

{
  "browser_type": "chrome_128",
  "operating_system": "Windows 11",
  "screen_resolution": "1920x1080",
  "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36..."
}

Lý do đằng sau là Canvas/WebGL Fingerprint của Google. Google Anti-Bot AI không chỉ chấm điểm dựa trên "Mật khẩu đúng không?". Nó còn kiểm tra: "Ủa tài khoản này hôm qua đăng nhập cấu hình Điện thoại, mà hôm nay lại là Laptop. Mà tại sao độ phân giải Laptop lại là 123x456 (Ảo)?".

Phía Cài Đặt Profile của Traffic Tools bắt buộc phải nạp và giữ bất động những thông số giả lập phần cứng này. Nó giúp Master Node và Slave Node cấu hình Chrome Argument --window-size=1920,1080 khớp dính với Tài khoản. Tài khoản đó sẽ "Sống Mãi" như 1 con người thật!

XVII. DECOUPLING: TẠI SAO CÓ `PROFILE_CRUD.GO` VÀ `PROFILE_OPERATIONS.GO`

Thông thường, lập trình viên Backend thường ném tất cả 10-20 HTTP Handler vào 1 file Service (ví dụ profile_service.go).

Nhưng ở Traffic Tools V2, Go-Fiber được tách ra triệt để:

profile_crud.go: Chỉ lo chuyện Thêm, Sửa (Update Name/Email), Xóa (Delete Row). Phục vụ Database thô sơ.

profile_operations.go: Nhận các Lệnh phức tạp có tính Toán Logic. Vi dụ Hàm RecordFailedLogin phân tích số lần rớt mạng. Hoặc BulkUpdateProfiles cập nhật Hàng Lọt State.

Đặc biệt ở profile_crud.go, ta thấy API tạo Profile TỰ ĐỘNG CHỐNG OVERRIDE ID:

Đây là nghệ thuật Clean Code đỉnh cao để bảo vệ Application Layer khỏi Data Poisoning từ Payload JSON.

XVIII. TỔNG KẾT VÀ BÀI TOÁN TƯƠNG LAI CỦA PROFILE MANAGEMENT

Điểm Sáng Trọng Điểm:

Thiết kế Single Responsibility (SRP): Tách file Vue (Modal/Trang Cột) và Tách file Go (Crud/Ops/Cleanup).

Kỹ nghệ UI mượt mà: Ứng dụng JSX render createColumns của NaiveUI để cứu Tốc độ RAM Browser khi tải 10,000 Tài khoản đồng thời kích hoạt Event Timers cho Từng Hàng Hàng Loạt.

Database Security: Áp dụng giới hạn Rate Limit cực kỳ nhân đạo (Max 100 User/Request Chunk) cho chức năng Import.

Sống Chung với AI: Cơ chế Tính Số lượng Phiên Đã Cào CountDocuments của report_task để loại Profile đó ra khỏi Pool, bảo quản mạng sống cho Google Account của Công ty.

Khuyến Nghị Kiến Trúc Nâng Cấp Tương Lai:

Vì Google Account thay đổi Policy thuật toán mỗi tuần, hệ thống cần có Caching Memory. Thay vì hàm GetAvailableProfiles gọi Select Mongo liên tục từ hàng nghìn Bot, Có thể áp dụng Redis Caching với List Pop (Redis SET). Pop Profile ra, khi nào dùng xong Push trả lại SET. Giúp MySQL / MongoDB rảnh tay xử lý những task nặng hơn (Báo Cáo Biểu Đồ).

XIX. THUẬT TOÁN ĐIỀU CHUYỂN PHÂN TRANG STORE BẰNG ACTION COMPOSITION

Trong Cấu trúc siêu to khổng lồ của Pinia, như đã đề cập ở Phần II, File useProfilePaginationActions.ts chịu trách nhiệm 1 việc nhỏ bé nhưng cực kỳ sinh tử:

Đây là pattern có tên gọi là Functional Programming injected into State Machine. Thay vì gọi this.fetchProfiles() theo phong cách Class-Based/Options API cổ lỗ sĩ, Mọi thứ được gói kín trong 1 Factory Function cấp phát store: any từ gốc mẹ. Nó giống như việc "Cho Mượn Pinia Store" để làm biến Local.
Ưu điểm khổng lồ là Unit Test: Đội ngũ QC (Tester) có thể Test riêng file này bằng cách Mock (Giả lập) store thành Object Trống { currentPage: 1, fetchProfiles: () => {} }. 100% Khả năng Test tự động thành công không cần phải khởi chạy môi trường Browser tốn kém bộ nhớ.

XX. DÂY CHUYỀN LẮP RÁP (PROXY ATTACHMENT) VÀ GOOGLE AI

Mạng lưới Profile Management không thể sống một mình nếu thiếu IPv4/IPv6 thay đổi tĩnh/động. Cột proxy_id và proxy_region trong Bảng Profile là thứ sống còn.

1 Profile Google = 1 User Agent Chrome 128 = 1 Browser Hardware Info = 1 IP Proxy (Không Cấp Chung!).

Khi Backend Fiber truy suất API Service Create Profile:

Việc dán chặt IP này tạo ra 1 "Fingerprint Ổn Định". Thuật toán Google Search có 1 con AI tên là Behavior Analysis. Nếu hôm nay Profile admin@gmail.com ở IP Thái Bình (Việt Nam), ngày mai nó vọt sang IP New York, Mạng lưới Google sẽ đưa Account vào trạng thái Check Point (Mở khóa Captcha). Điều này khiến Bot Tool Chết hàng rạt.

Hệ thống Traffic Tools buộc phải Map Server (Node Máy Cắm) -> Phải có Proxy cùng Region (Tỉnh Thành/Quốc gia). Đây là sự trỗi dậy của biến country và server_id. Admin chọn Nén (Map) Profile cho Máy chủ gốc tại VN, thì Proxy cấp phát cũng có Prefix là VN. Mảng Business Logic này là bức tường lửa sống chết phân biệt Hệ thống Boot Cùi Bắp và Hệ thống Cày View Siêu Cấp.

XXI. THE GIGA SUMMARY - HOÀN THIỆN MÔ HÌNH PROFILE MODULE

Tổng dọn lại những thành tựu của 2 team (Go Backend + Vue Frontend):

Về Frontend:

Dùng Form NModel Lớn Nhất: ProfileEditModal.vue tự điều biến Fields để đối phó với sự khắc nghiệt của Yêu cầu Bảo vệ Google Account.

Timer Sync Data: Quét Countdown theo giây không cần Websocket. Thay vì 10,000 Profile xin Ping từ Backend mỗi giây (Gây Server Down 503), Frontend tự đếm thời gian trừ hao thời gian Cooldown. Server khoẻ re!

Filter Data 2 Chiều: ProfileFilters.vue thiết kế kiểu Emit Trigger V-Model, chớp tắt Filter Tag đẹp đẽ, đẳng cấp như Data Table của Github.

Về Backend:

Golang Pointer Mapping: Toàn bộ Array Output của Profiles được nén thành String ID *[Hex]bson.ObjectID.

Lá Chắn Chết Chùm Session: Không đụng vào bảng Master profiles để ghi trạng thái Đã Logged In, tạo bảng con profile_sessions để chống Lỗi Read/Write Deadlock ở Mongo DB!

Auto Penalty & Cleanup: Có Service Cleanup_handlers.go dùng làm Cronjob bảo vệ File System Mongo không bị cháy RAM với rác Tracking Cookie 3 tháng. Giới hạn Cào (Daily Report Limits) bằng lệnh Lọc ở hàm GetRandomProfiles().

Đến đây, Hệ thống Profile Google Quản Trị đã được soi rọi dưới đủ 3 góc độ: Thuật Toán View, Bộ Nhớ Local, và Database Architect Mongo DB O(N). Đóng gói hoàn chỉnh!

XXII. NGHỆ THUẬT RENDER ÁNH SÁNG VỚI HYPERSCRIPT (`useProfileTable.ts`)

Trong phần trước, ta đã đề cập ProfileTable.vue vô cùng mượt mà. Bí thuật thực sự nằm ở file useProfileTable.ts. Component này phô diễn kỹ năng sử dụng hàm h() (Hyperscript/Virtual DOM rendering) của Vue 3:

Tại sao lại viết Code Javascript nồng nặc mùi HTML như thế này?
Trả lời: Khi NaiveUI gắn dữ liệu vào thẻ <n-data-table>, nếu ta sử dụng kịch bản <template> trong thẻ .vue thông qua vòng lặp v-for hoặc slots, Vue Compiler sẽ hao tốn Resource để Parse Template thành Render Function.
Bằng cách lập trình trực tiếp bằng RENDER FUNCTION h(), Kỹ sư Front-End Bypass qua lớp Compile Template, Đẩy thẳng Cấu trúc Virtual Object vào Browser DOM. Điều này tiết kiệm 30-40% bộ nhớ RAM Của Chrome khi Render 1 Bảng Log dài hàng vạn Dòng.

Cấu trúc JSX-Mapping cũng xử lý linh hoạt Tag màu của Tool Mode:

Kiến trúc này biến User-Interface trở thành một Cỗ máy Phân Luồng Màu Cờ Lập Trình thuần túy (Pure Functional Component). Hoàn toàn Không phụ thuộc HTML Markup!

XXIII. NGĂN CHẶN XUNG ĐỘT STATE Ở FRONT-END KHI XOÁ MỀM (SOFT DELETE)

Traffic Tools không bao giờ dùng thuật toán Xoá Cứng (Hard Delete) đối với Profile. Nếu Xóa cứng một profile, toàn bộ Biểu đồ Thống kê ngày hôm qua (đã cày bao nhiêu view) sẽ Bốc hơi do mất Khoá Ngoại (Foreign Key) profile_id.
Hệ thống sử dụng khái niệm Soft Delete.

Backend Cập nhật trạng thái status: 'deleted' và gán Timestamp vào deleted_at.

Frontend trong useProfileTable.ts xử lý cực mềm mại bằng cách Kiểm tra Cờ isDeleted:

Và ở Hàm Sắp xếp (Sorter), thay vì chọc thẳng vào Index Array, Hệ thống tự động đẩy các phần tử đã xóa xuống cuối bằng Tweak Sort Date:

7. Quản lý tài khoản Google (Google Account Management)

CẨM NANG TOÀN DIỆN VỀ KIẾN TRÚC VÀ IMPLEMENTATION "QUẢN LÝ TÀI KHOẢN GOOGLE" (PROFILE MANAGEMENT)#

I. TẦNG NHÌN TỔNG QUAN VÀ SỨ MỆNH MODULE#

II. KIẾN TRÚC MÃ NGUỒN FRONTEND (VUE 3 - COMPOSITION API)#

1. Phép Màu Quản Lý Store Bằng Composition Đa Tầng Của Pinia#

2. Định Nghĩa Data Type Profile Khổng Lồ#

III. THUẬT TOÁN ĐỒNG HỒ ĐẾM NGƯỢC THỜI GIAN THỰC (useCountdownTimer)#

1. Kiến trúc Timer của Frontend#

IV. QUÉT KHỐI BULK ADD (THÊM TÀI KHOẢN HÀNG LOẠT) VÀ CẠM BẪY#

V. CẠM BẪY N+1 DATABASE VÀ QUY LUẬT BULK ADD Ở BACKEND (profile_crud_handlers.go)#

VI. QUY LUẬT GIAO VIỆC (TASK DISPATCHING) BẢO VỆ TÀI KHOẢN KHÔNG BỊ BAN#

VII. CHIẾN BINH ÂM THẦM: BULK ACTIONS VÀ TRẠNG THÁI PROFILE#

VIII. KIẾN TRÚC PHIÊN LÀM VIỆC ĐA NHIỆM (PROFILE SESSIONS)#

1. Tại sao cần tách Bảng Session?#

2. Định nghĩa DTO CreateProfileSessionRequest#

IX. CƠ CHẾ TRỪNG PHẠT AI (FAILED LOGIN ATTEMPTS)#

X. CÂY CẤU TRÚC MODAL COMPOSABLE: PROFILETABLE.VUE#

XI. NGHIỆP VỤ LIÊN HOÀN (REPORT TASKS BY DOMAIN) TRONG PROFILE#

XII. NGHỆ THUẬT LỌC VÀ TÌM KIẾM (PROFILEFILTERS.VUE) KHÔNG CẦN NÚT SEARCH#

XIII. RÁC TRÌNH DUYỆT: THU DỌN CHIẾN TRƯỜNG BẰNG CLEANUP_HANDLERS.GO#

XIV. ĐO TAI BIẾN TÀI KHOẢN TỪ XA (TestProfileConnection)#

XV. KĨ THUẬT RÀNG BUỘC (CONDITIONAL RENDERING) Ở PROFILE_EDIT_MODAL.VUE#

Đồng bộ hóa biến Props (watch)#

XVI. SỰ "HOANG TƯỞNG" BẢO MẬT (HARDWARE BAN EVASION)#

XVII. DECOUPLING: TẠI SAO CÓ PROFILE_CRUD.GO VÀ PROFILE_OPERATIONS.GO#

XVIII. TỔNG KẾT VÀ BÀI TOÁN TƯƠNG LAI CỦA PROFILE MANAGEMENT#

Điểm Sáng Trọng Điểm:#

Khuyến Nghị Kiến Trúc Nâng Cấp Tương Lai:#

XIX. THUẬT TOÁN ĐIỀU CHUYỂN PHÂN TRANG STORE BẰNG ACTION COMPOSITION#

XX. DÂY CHUYỀN LẮP RÁP (PROXY ATTACHMENT) VÀ GOOGLE AI#

XXI. THE GIGA SUMMARY - HOÀN THIỆN MÔ HÌNH PROFILE MODULE#

Về Frontend:#

Về Backend:#

XXII. NGHỆ THUẬT RENDER ÁNH SÁNG VỚI HYPERSCRIPT (useProfileTable.ts)#

XXIII. NGĂN CHẶN XUNG ĐỘT STATE Ở FRONT-END KHI XOÁ MỀM (SOFT DELETE)#