Vâng, cảm ơn đánh giá chân thành của bạn ^^ Như bạn đã nói, việc trình bày quy trình xử lý ở cấp nguồn bằng cách sử dụng tính năng gỡ lỗi trong bài giảng có thể không cần thiết theo một nghĩa nào đó. Thời gian giảng tương đối dài, có một số điều không thể dễ dàng hiểu được nếu chỉ xem quá trình gỡ lỗi một lần. Tuy nhiên, lý do đưa các yếu tố gỡ lỗi vào bài giảng là để cung cấp sự hiểu biết rõ ràng về quy trình xử lý nội bộ của khung hoặc thư viện. Tất nhiên, bạn không cần biết và không thể biết các quy trình và luồng nội bộ của tất cả các mô-đun và API. Theo quan điểm của tôi, nếu biết quy trình xử lý nội bộ của API này là quan trọng khi triển khai một chức năng nhất định, tôi sẽ giải thích quy trình xử lý tổng thể thông qua việc gỡ lỗi. Việc gỡ lỗi sẽ không có ý nghĩa gì nếu nó kết thúc bằng việc tự gỡ lỗi. Bằng cách hiểu rõ ràng mục đích và nguyên tắc thiết kế API thông qua việc gỡ lỗi, tôi hướng tới mục tiêu không chỉ đơn giản là sử dụng API mà còn phát triển khả năng tùy chỉnh mở rộng hoặc áp dụng nó theo ý muốn. Mặc dù chúng tôi không trực tiếp thiết kế hoặc tạo Spring Security, nhưng đây là một cách tốt để tham gia gián tiếp vào thiết kế công nghệ cốt lõi thông qua việc gỡ lỗi và trải nghiệm một phần cách nó được triển khai. Khi quá trình này được lặp lại và tích lũy, các ứng dụng tùy chỉnh phức tạp có thể thực hiện được không chỉ dựa trên cách sử dụng API cơ bản mà còn dựa trên sự hiểu biết sâu sắc về công nghệ và có thể phản hồi nhanh chóng khi xảy ra trường hợp ngoại lệ hoặc sự cố. Tuy nhiên, nếu nhìn vào cấp độ nguồn quá nhiều, bạn có thể bỏ lỡ bức tranh tổng thể nên phải điều chỉnh phân tích theo trình độ và khả năng hiểu biết của mình. Tôi sẽ tiếp tục suy nghĩ và phát triển để có thể kết hợp việc sử dụng tính năng sửa lỗi ở mức độ thích hợp vào bài giảng của mình bằng cách điều chỉnh nhịp độ và nhịp độ. Cảm ơn bạn một lần nữa vì đánh giá có giá trị của bạn ^^