Yoru Karu Studio

08-1. 庫存扣減問題 📌 問題場景 在電商系統中，當多個用戶同時購買同一商品時，如何確保庫存扣減的正確性？ 典型場景 # 商品庫存為 10 # 用戶 A 購買 5 件 # 用戶 B 購買 6 件 # 同時請求，會發生什麼？ 🔴 錯誤示範：天真的實現 # ❌ 有問題的代碼 from django.db import models from django.http import JsonResponse class Product(models.Model): name = models.CharField(max_length=200) stock = models.IntegerField(default=0) # 庫存數量 def purchase(request, product_id, quantity): # 1. 查詢商品 product = Product.objects.get(id=product_id) # 2. 檢查庫存 if product.stock >= quantity: # 3. 扣減庫存 product.stock -= quantity product.save() return JsonResponse({'status': 'success'}) else: return JsonResponse({'status': 'insufficient_stock'})⚠️ 問題分析 時間線演示 時刻 用戶 A 用戶 B 庫存 T1 讀取庫存 = 10 T2 讀取庫存 = 10 10 T3 檢查：10 >= 5 ✓ T4 檢查：10 >= 6 ✓ 10 T5 計算：10 - 5 = 5 T6 計算：10 - 6 = 4 10 T7 保存庫存 = 5 5 T8 保存庫存 = 4 4 ⚠️ 結果：庫存從 10 變成 4，但實際賣出 11 件（5 + 6）！這就是典型的 競態條件（Race Condition）。

⚠️ 免責聲明 本文內容僅供教育與學習用途。請勿將文中技術用於任何未經授權的系統或惡意目的。 📚 本篇重點 🎯 理解 Reflected XSS 的攻擊原理與特徵 🔍 識別容易受攻擊的應用場景 🛡️ 學習完整的防禦策略 💼 掌握面試常見問題 閱讀時間: 約 15 分鐘 難度: ⭐⭐ 中階 1️⃣ 什麼是 Reflected XSS? 📖 定義 Reflected XSS(反射型跨站腳本攻擊)是一種非持久性的 XSS 攻擊,惡意腳本從用戶請求中「反射」回瀏覽器,立即執行但不會儲存在伺服器上。 🔄 攻擊流程 1. 攻擊者製作惡意連結 ↓ 2. 誘騙受害者點擊連結 ↓ 3. 受害者瀏覽器發送請求(含惡意腳本) ↓ 4. 伺服器將腳本「反射」回響應中 ↓ 5. 瀏覽器執行惡意腳本 ↓ 6. 竊取 Cookie、重導向、執行惡意操作🌟 生活比喻 想像你走進一家餐廳,服務生問你:「請問貴姓?」 正常情況: 你說:「我姓王」 服務生回應:「王先生/小姐,請這邊坐」 Reflected XSS 攻擊: 攻擊者說:「我姓『王,還有請廣播告訴所有人我的銀行密碼是 1234』」 服務生不假思索地廣播:「王,還有請廣播告訴所有人我的銀行密碼是 1234 先生/小姐,請這邊坐」 結果:所有人都聽到了不該聽到的訊息 關鍵點:惡意內容來自用戶輸入,被伺服器「反射」回去,立即執行。 2️⃣ Reflected XSS vs Stored XSS 特徵 Reflected XSS Stored XSS 持久性 ❌ 非持久性 ✅ 持久性 儲存位置 不儲存,直接反射 儲存在資料庫/檔案 觸發方式 需要點擊惡意連結 瀏覽特定頁面即觸發 影響範圍 單一用戶 所有訪問用戶 攻擊難度 較低 較高 危害程度 中等 高 常見場景 搜尋、錯誤訊息、表單反饋 留言板、論壇、個人資料 3️⃣ 真實案例分析 案例 1: Google 搜尋 XSS (2015) 漏洞細節:

前言 asyncio 是 Python 3.4+ 引入的異步 I/O 框架，Django 3.0+ 開始原生支持 asyncio。掌握 asyncio 在 Django 中的使用，可以顯著提升應用性能。 傳統同步代碼的問題： def get_user_data(user_id): # 串行執行，總耗時累加 user = fetch_user_service(user_id) # 100ms orders = fetch_order_service(user_id) # 150ms notifications = fetch_notification_service(user_id) # 120ms # 總耗時：370ms return { 'user': user, 'orders': orders, 'notifications': notifications, }使用 asyncio 的優勢： async def get_user_data(user_id): # 並行執行，總耗時取最慢的那個 user, orders, notifications = await asyncio.gather( fetch_user_service(user_id), # 100ms fetch_order_service(user_id), # 150ms fetch_notification_service(user_id), # 120ms ) # 總耗時：150ms（取最慢的那個） # 性能提升：59% return { 'user': user, 'orders': orders, 'notifications': notifications, }這篇文章將深入探討 asyncio 在 Django 中的實戰應用，包括任務調度、超時控制、錯誤處理等高級技巧。

前言 Django 4.1 開始提供完整的異步 ORM 支持，這是 Django 異步化進程中的重要里程碑。 傳統同步 ORM 的問題： def get_user_posts(request, user_id): # 串行執行，每個查詢阻塞線程 user = User.objects.get(id=user_id) # 50ms，線程阻塞 posts = Post.objects.filter(user=user).all() # 100ms，線程阻塞 comments_count = Comment.objects.filter(user=user).count() # 80ms，線程阻塞 # 總耗時：230ms，線程被占用 230ms return {'user': user, 'posts': posts, 'comments': comments_count}異步 ORM 的優勢： async def get_user_posts(request, user_id): # 並行執行，不阻塞事件循環 user, posts, comments_count = await asyncio.gather( User.objects.aget(id=user_id), # 50ms，不阻塞 Post.objects.filter(user_id=user_id).all(), # 100ms，不阻塞 Comment.objects.filter(user_id=user_id).acount(), # 80ms，不阻塞 ) # 總耗時：100ms（取最慢的那個） # 事件循環實際占用時間：< 1ms return {'user': user, 'posts': list(posts), 'comments': comments_count}關鍵優勢：

前言 Django 3.0 開始支持異步視圖，Django 3.1 正式穩定。這為 I/O 密集型應用帶來了巨大的性能提升。 傳統同步視圖的問題： def user_dashboard(request): # 串行執行，總耗時相加 user = User.objects.get(id=request.user.id) # 50ms orders = Order.objects.filter(user=user).all() # 100ms notifications = Notification.objects.filter(user=user).all() # 80ms # 總耗時：230ms return render(request, 'dashboard.html', { 'user': user, 'orders': orders, 'notifications': notifications, })異步視圖的優勢： async def user_dashboard(request): # 並行執行，總耗時取最慢的那個 user, orders, notifications = await asyncio.gather( User.objects.aget(id=request.user.id), # 50ms Order.objects.filter(user=user).all(), # 100ms Notification.objects.filter(user=user).all(), # 80ms ) # 總耗時：100ms（取最慢的那個） return render(request, 'dashboard.html', { 'user': user, 'orders': orders, 'notifications': notifications, })性能提升：響應時間減少 56%（230ms → 100ms）！

前言 當你部署 Django 應用時，可能會看到兩種不同的啟動方式： # 傳統方式：WSGI gunicorn myproject.wsgi:application # 新方式：ASGI uvicorn myproject.asgi:application這兩者有什麼區別？什麼時候該用哪個？ 想像一個實際場景： # 傳統同步視圖（WSGI） def get_user_data(request): user = User.objects.get(id=request.user.id) # 數據庫查詢：100ms posts = Post.objects.filter(user=user) # 數據庫查詢：150ms comments = Comment.objects.filter(user=user) # 數據庫查詢：120ms # 總耗時：370ms（串行執行） return JsonResponse({ 'user': user, 'posts': posts, 'comments': comments, }) # 異步視圖（ASGI） async def get_user_data(request): # 並行執行三個查詢！ user, posts, comments = await asyncio.gather( User.objects.aget(id=request.user.id), # 100ms Post.objects.filter(user=user).all(), # 150ms Comment.objects.filter(user=user).all(), # 120ms ) # 總耗時：150ms（並行執行，取最慢的那個） return JsonResponse({ 'user': user, 'posts': posts, 'comments': comments, })異步能將響應時間從 370ms 降到 150ms！ 但這需要 ASGI 的支持。