Khi ứng dụng còn nhỏ, chúng ta có thể nhìn vào màn hình và đoán lỗi.
Nhưng khi Blog CMS bắt đầu có nhiều Controller, Model, Middleware, Event, Queue, Mail, Cache và Storage thì việc theo dõi hoạt động của ứng dụng trở nên rất quan trọng.
Laravel cung cấp hệ thống Logging và nhiều công cụ Debug giúp chúng ta biết:
Request nào đang xảy ra.
Query nào được thực thi.
Exception nào xuất hiện.
User nào đang thực hiện hành động.
Queue nào đang chạy.
Ứng dụng đang gặp vấn đề ở đâu.
Trong bài này chúng ta tìm hiểu ba công cụ chính:
Log
Debugbar
Telescope
1. Logging là gì?
Logging là quá trình ghi lại thông tin hoạt động của ứng dụng.
Ví dụ:
User đăng nhập
Post được tạo
Post được cập nhật
File được upload
Email được gửi
Exception xảy ra
Thay vì chỉ nhìn thấy:
500 Server Error
Log có thể cho chúng ta biết:
16:20:31
PostController@update
Post ID: 25
Image upload failed
Nhờ đó việc tìm lỗi trở nên dễ dàng hơn.
2. Laravel Logging
Laravel sử dụng hệ thống Logging dựa trên:
Monolog
Ứng dụng có thể ghi Log thông qua:
use Illuminate\Support\Facades\Log;
Ví dụ:
Log::info('Laravel 13 đang chạy');
3. Log các mức độ khác nhau
Laravel cung cấp nhiều Log level.
Một số level thường gặp:
emergency
alert
critical
error
warning
notice
info
debug
Có thể hình dung:
Emergency
↑
Alert
↑
Critical
↑
Error
↑
Warning
↑
Notice
↑
Info
↑
Debug
Trong ứng dụng thông thường, chúng ta thường sử dụng:
Log::debug();
Log::info();
Log::warning();
Log::error();
4. Log::info()
Dùng để ghi thông tin hoạt động bình thường:
Log::info('User đã đăng nhập');
Ví dụ trong Controller:
Log::info('Post được tạo thành công');
5. Log::warning()
Dùng khi có vấn đề cần chú ý nhưng chưa phải lỗi nghiêm trọng:
Log::warning(
'Post chưa có hình ảnh'
);
Ví dụ:
if (!$post->image) {
Log::warning(
'Post không có image',
[
'post_id' => $post->id,
]
);
}
6. Log::error()
Dùng khi xảy ra lỗi:
Log::error(
'Không thể upload image'
);
Có thể truyền thêm context:
Log::error(
'Không thể upload image',
[
'post_id' => $post->id,
]
);
Kết quả Log sẽ có thêm thông tin giúp chúng ta xác định lỗi.
7. Log::debug()
debug() thường được sử dụng trong quá trình phát triển:
Log::debug(
'Post update',
[
'post_id' => $post->id,
]
);
Ví dụ:
Post update
post_id = 15
Điều này rất hữu ích khi muốn theo dõi flow của code.
8. Log Context
Một trong những tính năng quan trọng của Log là Context.
Thay vì:
Log::info('Post updated');
ta có thể:
Log::info(
'Post updated',
[
'post_id' => $post->id,
'user_id' => auth()->id(),
]
);
Khi đó Log không chỉ nói:
Post updated
mà còn biết:
post_id
user_id
Đây là thói quen rất tốt khi xây dựng ứng dụng thực tế.
9. Log File mặc định
Laravel mặc định có thể ghi Log vào:
storage/logs/
Ví dụ:
storage/
└── logs/
└── laravel.log
Khi ứng dụng xảy ra lỗi hoặc chúng ta gọi:
Log::error(...)
thông tin có thể được ghi vào file Log.
10. Ví dụ đọc Log
Ví dụ Log:
Log::info(
'Post created',
[
'post_id' => 25,
'user_id' => 1,
]
);
Sau đó mở:
storage/logs/laravel.log
ta có thể tìm thấy thông tin tương ứng.
11. Log trong Blog CMS
Ví dụ khi tạo Post:
$post = Post::create($validated);
Log::info(
'Post created',
[
'post_id' => $post->id,
'user_id' => auth()->id(),
]
);
Khi cập nhật:
Log::info(
'Post updated',
[
'post_id' => $post->id,
'user_id' => auth()->id(),
]
);
Khi xóa:
Log::info(
'Post deleted',
[
'post_id' => $post->id,
'user_id' => auth()->id(),
]
);
Như vậy chúng ta có thể theo dõi các hoạt động quan trọng của Blog CMS.
12. try / catch và Log
Có thể kết hợp Exception với Log:
try {
$post->update($validated);
} catch (\Throwable $e) {
Log::error(
'Post update failed',
[
'post_id' => $post->id,
'error' => $e->getMessage(),
]
);
throw $e;
}
Điều này giúp ghi lại lỗi trước khi Exception tiếp tục được xử lý.
13. Log Exception
Có thể ghi trực tiếp Exception:
try {
// Code
} catch (\Throwable $e) {
Log::error(
'Unexpected error',
[
'exception' => $e,
]
);
throw $e;
}
Thông tin Exception giúp quá trình Debug dễ dàng hơn rất nhiều.
14. Logging không chỉ dành cho lỗi
Một quan niệm sai:
Log = Error
Không đúng.
Log có thể dùng để theo dõi:
Application Flow
User Activity
Business Event
Warning
Error
Performance
Ví dụ:
Log::info('Post published');
không phải lỗi.
Nó chỉ là thông tin quan trọng về hoạt động của hệ thống.
15. Logging Channel
Laravel hỗ trợ nhiều Log Channel.
Có thể hình dung:
Laravel
│
└── Logging
│
├── single
├── daily
├── stack
└── ...
Cấu hình nằm tại:
config/logging.php
16. Daily Log
Một cấu hình thường dùng là Daily Log.
Thay vì:
laravel.log
mọi thứ dồn vào một file rất lớn, có thể chia theo ngày:
laravel-2026-09-13.log
laravel-2026-09-14.log
laravel-2026-09-15.log
Điều này thuận tiện khi hệ thống hoạt động lâu dài.
17. Log Channel trong Code
Có thể chỉ định channel:
Log::channel('daily')->info(
'Post created'
);
Nếu project có channel riêng:
Log::channel('payments')->error(
'Payment failed'
);
Nhờ vậy những loại Log khác nhau có thể được tách riêng.
18. Debug là gì?
Debug là quá trình tìm nguyên nhân khiến chương trình hoạt động không đúng.
Ví dụ:
Form
↓
Request
↓
Controller
↓
Validation
↓
Model
↓
Database
Nếu dữ liệu không được lưu:
Lỗi nằm ở đâu?
Có thể là:
Form
Request
Validation
Controller
Model
Database
Debug giúp chúng ta tìm chính xác vị trí đó.
19. APP_DEBUG
Laravel có biến:
APP_DEBUG=true
Khi phát triển Local:
APP_DEBUG=true
có thể giúp hiển thị thông tin Debug chi tiết khi xảy ra Exception.
Ví dụ:
Exception
File
Line
Stack Trace
20. Production phải tắt Debug
Khi Deploy:
APP_ENV=production
APP_DEBUG=false
Không nên để:
APP_DEBUG=true
trên Website thật.
Bởi vì thông tin Debug có thể tiết lộ:
File path
Database information
Environment information
Stack trace
Application internals
Đây là vấn đề bảo mật.
21. dd()
Trong Laravel có:
dd();
Tên của nó có thể hiểu là:
Dump and Die
Ví dụ:
dd($post);
Laravel sẽ:
Hiển thị dữ liệu
↓
Dừng chương trình
22. dd() với nhiều biến
dd(
$request->all(),
$post,
$user
);
Rất hữu ích khi Debug Controller.
Ví dụ:
public function update(Request $request, Post $post)
{
dd(
$request->all(),
$post
);
// ...
}
23. dump()
Khác với:
dd()
dump() không dừng chương trình.
dump($post);
Sau đó code vẫn tiếp tục chạy.
Có thể:
dump($request->all());
$post->update($validated);
Trong Debug nhanh:
dump()
↓
xem dữ liệu
↓
tiếp tục chạy
Còn:
dd()
↓
xem dữ liệu
↓
dừng
24. Debugbar
Một công cụ rất phổ biến trong Laravel development là:
Laravel Debugbar
Package phổ biến:
barryvdh/laravel-debugbar
Debugbar có thể giúp quan sát:
Queries
Time
Memory
Route
Views
Events
Tùy cấu hình và phiên bản package.
25. Cài Laravel Debugbar
Trong môi trường development:
composer require barryvdh/laravel-debugbar --dev
Điểm quan trọng là:
--dev
Debugbar phục vụ quá trình phát triển, không phải chức năng người dùng cuối.
26. Debugbar hoạt động như thế nào?
Sau khi cài đặt, khi mở Website ở môi trường Local, Debugbar thường xuất hiện ở phía dưới trang.
Có thể hình dung:
┌─────────────────────────────┐
│ Blog CMS │
│ │
│ Nội dung Website │
│ │
└─────────────────────────────┘
───────────────────────────────
Debugbar
Queries | Route | Views | ...
───────────────────────────────
27. Debugbar — Query
Một tính năng rất hữu ích là xem Database Query.
Ví dụ Controller:
$posts = Post::with([
'user',
'category'
])->latest()->get();
Debugbar có thể cho chúng ta quan sát những Query được thực thi.
Ví dụ:
select * from posts
select * from users where ...
select * from categories where ...
Điều này đặc biệt hữu ích khi học:
Eloquent
Relationship
Eager Loading
N+1 Problem
28. N+1 Query
Ví dụ không tốt:
$posts = Post::all();
Sau đó trong Blade:
@foreach ($posts as $post)
{{ $post->category->name }}
@endforeach
Có thể dẫn tới nhiều Query không cần thiết.
Thay vào đó:
$posts = Post::with('category')->get();
Debugbar giúp chúng ta nhìn thấy sự khác biệt này.
29. Debugbar — Route
Debugbar cũng có thể giúp quan sát Route hiện tại:
GET /blog
Controller:
BlogController@index
Middleware:
web
auth
...
Điều này hữu ích khi Route trở nên phức tạp.
30. Debugbar — View
Có thể quan sát các View được render.
Ví dụ:
blog.index
components.blog.sidebar
components.post.card
Nếu một trang có quá nhiều View hoặc Component, Debugbar giúp chúng ta hiểu quá trình render.
31. Debugbar — Performance
Debugbar cũng có thể cho chúng ta thông tin về:
Time
Memory
Queries
Ví dụ:
Time: 120 ms
Memory: 18 MB
Queries: 8
Đây không phải công cụ benchmark production, nhưng rất hữu ích trong quá trình phát triển.
Ghi chú:
Khi deploy lên host (production), bạn nên tắt Debugbar để tránh lộ thông tin debug và giảm tải hệ thống.
01. Cấu hình môi trường
Debugbar mặc định chỉ nên chạy ở môi trường local. Bạn có thể ép tắt bằng biến môi trường.
- Trong file
.envtrên host, thêm dòng:APP_ENV=production - Đảm bảo không có cấu hình override nào cho Debugbar
02. Xóa Service Provider
Debugbar được đăng ký trong config/app.php hoặc thông qua auto-discovery.
- Mở file
config/app.php - Xóa hoặc comment đoạn đăng ký
Barryvdh\Debugbar\ServiceProvider::class - Deploy lại code lên host
03. Cấu hình trong config
Trong file config/debugbar.php, bạn có thể tắt bằng cách:
- Đặt
'enabled' => env('APP_DEBUG', false) - Trên host, đảm bảo
APP_DEBUG=falsetrong.env
04. Gỡ hẳn package (tuỳ chọn)
Nếu không cần Debugbar nữa, bạn có thể gỡ bỏ khỏi project.
- Chạy lệnh:
composer remove barryvdh/laravel-debugbar - Xóa migrations hoặc config liên quan nếu muốn dọn sạch
Tóm lại, cách đơn giản nhất là đặt APP_ENV=production và APP_DEBUG=false trong .env trên host, Debugbar sẽ tự động không hiển thị.
Nếu muốn triệt để, bạn có thể xóa Service Provider hoặc gỡ package.
32. Telescope
Laravel còn có một công cụ Debug mạnh hơn:
Laravel Telescope
Telescope là một debugging assistant dành cho Laravel.
Nó cung cấp giao diện để quan sát nhiều hoạt động của ứng dụng.
Ví dụ:
Requests
Commands
Schedule
Jobs
Batches
Database Queries
Exceptions
Logs
Mail
Notifications
Cache
Tùy phiên bản và cấu hình, Telescope cung cấp nhiều watcher khác nhau.
33. Cài Telescope
Có thể cài bằng:
composer require laravel/telescope
Sau đó:
php artisan telescope:install
và:
php artisan migrate
Sau khi cài đặt, Telescope có Dashboard riêng.
Ghi chú: vào link này trên local: http://127.0.0.1:8000/telescope
34. Telescope Dashboard
Có thể hình dung:
Laravel Application
│
▼
Telescope
│
┌──────┼───────────────┐
▼ ▼ ▼
Request Query Exception
│ │ │
▼ ▼ ▼
Job Mail Log
Dashboard giúp Developer quan sát hệ thống từ một nơi.
35. Telescope — Requests
Telescope có thể theo dõi Request.
Ví dụ:
GET /blog
Có thể quan sát thông tin liên quan đến Request, Response và thời gian xử lý tùy watcher/cấu hình.
Điều này hữu ích khi Debug:
404
403
500
36. Telescope — Queries
Telescope có thể ghi nhận Database Query.
Ví dụ:
select * from posts
và:
select * from categories
Điều này rất hữu ích khi phân tích:
Eloquent
Relationship
N+1
Slow Query
37. Telescope — Exceptions
Nếu ứng dụng xảy ra Exception:
ModelNotFoundException
QueryException
ValidationException
...
Telescope có thể giúp Developer theo dõi Exception tùy cấu hình watcher.
Thay vì chỉ biết:
500
chúng ta có thể điều tra:
Exception
↓
Request
↓
Query
↓
Application Flow
38. Telescope — Jobs
Trong bài Queue trước đó chúng ta đã tìm hiểu Job.
Ví dụ:
SendWelcomeEmail::dispatch($user);
Telescope có thể giúp theo dõi hoạt động liên quan đến Job.
Có thể hình dung:
Job dispatched
↓
Queue
↓
Worker
↓
Job processed
Nếu Job thất bại, công cụ quan sát như Telescope rất hữu ích trong quá trình Debug.
39. Telescope — Mail
Ứng dụng Blog CMS có thể gửi:
Email
Notification
Telescope có thể giúp Developer theo dõi hoạt động Mail trong môi trường development tùy watcher/configuration.
Điều này rất hữu ích khi:
Email không gửi
Email gửi sai
Mailable không chạy
Queue Mail bị lỗi
40. Telescope — Notifications
Tương tự Mail, Telescope có thể hỗ trợ quan sát Notifications.
Ví dụ:
PostPublished
↓
Notification
↓
User
Nếu Notification không hoạt động như mong muốn, Telescope giúp chúng ta có thêm dữ liệu để điều tra.
41. Telescope và Production
Telescope là công cụ rất mạnh.
Nhưng không nên hiểu:
Telescope
=
luôn bật công khai
Đặc biệt với Production, cần cân nhắc:
Authorization
Storage
Performance
Sensitive Data
Retention
Telescope Dashboard nên được bảo vệ bằng authorization phù hợp.
Laravel cũng cung cấp cơ chế pruning để giới hạn lượng dữ liệu Telescope lưu trữ. (laravel.com)
Ghi chú:
Khi đưa ứng dụng Laravel lên host (production), bạn nên tắt Telescope để tránh lộ dữ liệu debug và giảm tải hệ thống. Có vài cách phổ biến:
01. Xóa Service Provider
Telescope được đăng ký trong AppServiceProvider hoặc bootstrap/providers.php.
- Mở file
App\Providers\AppServiceProvider - Xóa hoặc comment đoạn đăng ký
TelescopeServiceProvider - Deploy lại code lên host
02. Cấu hình môi trường
Telescope mặc định chỉ chạy ở môi trường local. Bạn có thể ép tắt bằng biến môi trường.
Trong file .env trên host:
- Thêm dòng:
APP_ENV=production - Đảm bảo không có cấu hình override nào cho Telescope
03. Xóa route Telescope
Nếu vẫn còn route /telescope, bạn có thể xóa hẳn.
- Xóa file
TelescopeServiceProvider - Hoặc comment toàn bộ nội dung trong đó
- Chạy lại
composer dump-autoload
04. Gỡ hẳn package (tuỳ chọn)
Nếu không cần Telescope nữa, bạn có thể gỡ bỏ khỏi project.
- Chạy lệnh:
composer remove laravel/telescope - Xóa migrations liên quan nếu muốn dọn sạch database
Tóm lại, cách đơn giản nhất là đặt APP_ENV=production trong .env trên host, Telescope sẽ tự động không hiển thị.
Nếu muốn triệt để, bạn có thể xóa Service Provider hoặc gỡ package.
42. Debugbar và Telescope khác nhau
Có thể hiểu đơn giản:
Debugbar
Debug ngay trên trang đang mở
Phù hợp:
Local Development
Query nhanh
Route
View
Performance
Telescope
Dashboard quan sát ứng dụng
Phù hợp:
Requests
Queries
Jobs
Mail
Notifications
Exceptions
Logs
Có thể hình dung:
DEBUG
┌──────┴──────┐
│ │
Debugbar Telescope
│ │
Nhanh Chi tiết
Local Dashboard
43. Log vs Debugbar vs Telescope
| Công cụ | Mục đích |
|---|---|
Log | Ghi thông tin ứng dụng |
dd() | Kiểm tra dữ liệu nhanh |
dump() | Kiểm tra dữ liệu nhưng tiếp tục chạy |
| Debugbar | Quan sát request hiện tại |
| Telescope | Quan sát hoạt động của Laravel |
Không có công cụ nào thay thế hoàn toàn công cụ còn lại.
44. Quy trình Debug thực tế
Khi Blog CMS gặp lỗi:
User báo lỗi
↓
Kiểm tra Log
↓
Kiểm tra Exception
↓
Kiểm tra Request
↓
Kiểm tra Query
↓
Kiểm tra Controller
↓
Kiểm tra Model
↓
Kiểm tra Database
Trong Local có thể dùng:
dd()
dump()
Debugbar
Telescope
Trong Production nên ưu tiên:
Log
Monitoring
Exception Tracking
và tránh để thông tin Debug nhạy cảm hiển thị cho người dùng.
45. Ví dụ Debug Post Update
Giả sử:
public function update(
Request $request,
Post $post
) {
$validated = $request->validate([
'title' => ['required'],
'content' => ['required'],
]);
$post->update($validated);
return redirect()
->route('posts.index');
}
Nhưng dữ liệu không được cập nhật.
Bước đầu:
dd($request->all());
Kiểm tra:
Request có dữ liệu không?
Sau đó:
dd($validated);
Kiểm tra:
Validation có đúng không?
Sau đó:
dd($post);
Kiểm tra:
Route Model Binding có đúng Post không?
Cuối cùng kiểm tra:
Debugbar
hoặc:
Telescope
để xem Query.
46. Debug Upload Image
Giả sử Upload Image không hoạt động.
Có thể kiểm tra:
dd(
$request->hasFile('image'),
$request->file('image')
);
Nếu:
false
kiểm tra Form:
enctype="multipart/form-data"
Nếu có file:
UploadedFile
thì kiểm tra:
dd(
$request->file('image')->getMimeType()
);
Sau đó kiểm tra Storage.
Đây là cách Debug theo từng tầng thay vì đoán.
47. Debug Database Query
Ví dụ:
$posts = Post::with([
'user',
'category'
])->latest()->get();
Nếu nghi ngờ Query quá nhiều:
Debugbar
hoặc:
Telescope
có thể giúp quan sát Query.
Ta có thể phát hiện:
N+1
Query dư thừa
Query quá nhiều
Query chậm
48. Không dùng dd() để Debug Production
Không nên để:
dd($request->all());
trên Website thật.
Bởi vì:
dd()
↓
dừng request
↓
hiển thị dữ liệu
Nếu dữ liệu chứa thông tin nhạy cảm, hậu quả có thể nghiêm trọng.
Sau khi Debug xong:
XÓA dd()
49. Debug và Security
Debug phải luôn đi cùng Security.
Không nên Log:
Password
API Secret
Private Key
Credit Card
Authentication Token
Ví dụ không nên:
Log::info(
'Login',
[
'password' => $request->password,
]
);
Thay vào đó chỉ Log thông tin cần thiết:
Log::info(
'User login',
[
'user_id' => $user->id,
]
);
50. Debug trong Blog CMS
Đến thời điểm này Blog CMS đã có:
Authentication
Authorization
CRUD
Upload
Soft Delete
Scope
Observer
Event
Listener
Queue
Mail
Notification
Cache
Storage
Do đó Debug trở nên đặc biệt quan trọng.
Có thể hình dung:
BLOG CMS
│
┌───────────────┼───────────────┐
│ │ │
Log Debugbar Telescope
│ │ │
▼ ▼ ▼
Application Request Application
Events Queries Activity
Errors Views Jobs
Warning Route Mail
51. Mô hình Debug nên ghi nhớ
Khi gặp lỗi:
ERROR
│
▼
REPRODUCE
│
▼
INSPECT
│
┌────────┼────────┐
▼ ▼ ▼
Log Debugbar Telescope
│ │ │
└────────┼────────┘
▼
FIND CAUSE
│
▼
FIX
│
▼
TEST
Đây là tư duy Debug quan trọng hơn việc chỉ biết một vài lệnh.
52. Tổng kết
Trong bài này chúng ta đã tìm hiểu:
Logging.
Log::info().Log::warning().Log::error().Log::debug().Log Context.
Log File.
Log Channel.
Daily Log.
APP_DEBUG.dd().dump().Laravel Debugbar.
Query Debug.
N+1 Query.
Route Debug.
View Debug.
Performance Debug.
Laravel Telescope.
Telescope Requests.
Telescope Queries.
Telescope Exceptions.
Telescope Jobs.
Telescope Mail.
Telescope Notifications.
Debug Production.
Debug Security.
Quy trình Debug Blog CMS.
🎯 BÀI TẬP THỰC HÀNH
Bài tập 1 — Logging
Trong PostController, ghi Log khi:
Create Post
Update Post
Delete Post
Ví dụ:
Log::info(
'Post created',
[
'post_id' => $post->id,
'user_id' => auth()->id(),
]
);
Bài tập 2 — Debug Request
Sử dụng:
dd($request->all());
để kiểm tra dữ liệu Form Post.
Sau khi kiểm tra xong:
Xóa
dd()khỏi code.
Bài tập 3 — Debug Query
Cài:
composer require barryvdh/laravel-debugbar --dev
Sau đó kiểm tra:
Post Query
Category Query
User Query
Bài tập 4 — Tìm N+1
Thử:
$posts = Post::all();
sau đó truy cập:
{{ $post->category->name }}
Quan sát Query.
Sau đó sửa thành:
$posts = Post::with('category')->get();
và so sánh.
Bài tập 5 — Telescope
Cài:
composer require laravel/telescope
Sau đó:
php artisan telescope:install
và:
php artisan migrate
Truy cập Telescope Dashboard trong môi trường Local.
Thử:
Request
Query
Exception
Log
Job
Mail
và quan sát hoạt động của Blog CMS.
💡 GHI NHỚ
Log giúp chúng ta biết ứng dụng đã làm gì.
Debugbar giúp chúng ta nhìn thấy những gì đang xảy ra trong request hiện tại.
Telescope giúp chúng ta quan sát nhiều hoạt động của Laravel từ một Dashboard.
dd()vàdump()rất hữu ích khi học và Debug Local, nhưng phải loại bỏ khỏi Production code.
APP_DEBUG=true chỉ nên sử dụng trong môi trường phát triển.
Production phải sử dụng
APP_DEBUG=false.
Một Developer Laravel không chỉ cần biết viết:
$post->update();
mà còn phải biết trả lời:
Tại sao nó không update?
Query nào chạy?
Request có dữ liệu không?
Validation có đúng không?
Exception nằm ở đâu?
Database có vấn đề không?
Queue có chạy không?
File có tồn tại không?
Đó chính là lúc Logging và Debugging trở thành kỹ năng bắt buộc.
Với Blog CMS, chúng ta đã đi từ:
PHP
↓
Laravel
↓
Database
↓
Eloquent
↓
CRUD
↓
Authentication
↓
Authorization
↓
Advanced Laravel
↓
Logging & Debug
và đã hoàn thành Phần 8 — Nâng cao.
Bài tiếp theo: Bài 41 — REST API, bắt đầu Phần 9 — REST API, nơi Blog CMS sẽ mở dữ liệu cho các ứng dụng khác thông qua HTTP API.
x1
quay về MỤC LỤC




Không có nhận xét nào:
Đăng nhận xét