HI
RU
EN
ES
ZH
FR
DE
PT
AR
शुरुआती PHP डेवलपर्स की शीर्ष गलतियाँ: उन्नत स्तर
\n\nजब आप सरल स्क्रिप्ट से PHP में जटिल वेब एप्लिकेशन की ओर बढ़ते हैं, तो छिपे हुए खतरों की संख्या तेजी से बढ़ जाती है। कई डेवलपर्स, बुनियादी सिंटैक्स में महारत हासिल करने के बाद, सिस्टम संबंधी गलतियाँ करते हैं जो मेमोरी लीक, कमजोरियों और प्रदर्शन में गिरावट का कारण बनती हैं। इस लेख में, हम 4 उन्नत गलतियों पर चर्चा करेंगे जो अक्सर मध्य स्तर के डेवलपर्स में देखी जाती हैं, और दिखाएंगे कि उन्हें कैसे ठीक किया जाए।
\n\n1. सत्रों का गलत प्रबंधन और मेमोरी लीक
\n\nसबसे घातक गलतियों में से एक सत्रों के साथ गलत काम करना है। कई डेवलपर्स सत्रों में बड़ी मात्रा में डेटा संग्रहीत करते हैं (उदाहरण के लिए, DB से क्वेरी परिणाम या सीरियलाइज़्ड ऑब्जेक्ट)। यह न केवल काम को धीमा करता है, बल्कि सर्वर पर मेमोरी लीक का कारण भी बन सकता है।
\n\nसमस्या: स्क्रिप्ट निष्पादन के दौरान सत्र लॉक हो जाता है। यदि आप इसमें 10 MB डेटा संग्रहीत करते हैं, तो प्रत्येक अनुरोध इस मात्रा को पढ़ेगा और लिखेगा, और समानांतर अनुरोधों के मामले में, वे कतार में लग जाएंगे।
\n\nखराब कोड का उदाहरण:
\n<?php\nsession_start();\n// सत्र में 10000 रिकॉर्ड का एक ऐरे लोड करें\n$_SESSION['big_data'] = $db->query("SELECT * FROM logs")->fetchAll();\n?>समाधान: सत्र का उपयोग केवल पहचान (user_id, टोकन) के लिए करें। अन्य सभी डेटा को कैश (Redis, Memcached) या डेटाबेस में संग्रहीत करें।
\n\n<?php\nsession_start();\n$_SESSION['user_id'] = $user->id;\n// डेटा आवश्यकतानुसार प्राप्त करें\n$cache = new RedisCache();\n$data = $cache->get('user_data_' . $user->id);\nif (!$data) {\n $data = $db->query("SELECT * FROM logs WHERE user_id = ?", [$user->id])->fetchAll();\n $cache->set('user_data_' . $user->id, $data, 3600);\n}\n?>2. गलत कैशिंग और इनवैलिडेशन की अनदेखी
\n\nदूसरी सबसे आम गलती "हमेशा के लिए" कैशिंग करना है। डेवलपर्स कैश का TTL (जीवनकाल) 24 घंटे या उससे अधिक सेट करते हैं, और फिर आश्चर्य करते हैं कि उपयोगकर्ता पुराना डेटा क्यों देख रहे हैं। इससे भी बुरा है डेटाबेस में बदलावों को ध्यान में रखे बिना कैशिंग करना।
\n\nसमस्या: यदि आप उत्पादों की सूची को 1 घंटे के लिए कैश करते हैं, और एक प्रशासक ने कीमत बदल दी, तो उपयोगकर्ता अगले 60 मिनट तक पुरानी कीमत देखेंगे।
\n\nखराब कोड का उदाहरण:
\n<?php\n$cacheKey = 'product_list';\n$products = $cache->get($cacheKey);\nif (!$products) {\n $products = $db->query("SELECT * FROM products")->fetchAll();\n $cache->set($cacheKey, $products, 86400); // 24 घंटे\n}\n?>समाधान: कैश टैगिंग का उपयोग करें या डेटा बदलने पर जबरन इनवैलिडेशन करें।
\n\n<?php\n// उत्पाद अपडेट करते समय\nfunction updateProduct($id, $data) {\n $db->update("products", $data, ["id" => $id]);\n // कैश को इनवैलिडेट करें\n $cache->delete('product_list');\n $cache->delete('product_' . $id);\n}\n\n// पढ़ते समय\n$products = $cache->remember('product_list', 3600, function() use ($db) {\n return $db->query("SELECT * FROM products WHERE active = 1")->fetchAll();\n});\n?>3. "सुरक्षित" फ़ंक्शन के माध्यम से SQL-इंजेक्शन
\n\nकई डेवलपर्स मानते हैं कि यदि वे mysqli_real_escape_string() या addslashes() का उपयोग करते हैं, तो वे SQL-इंजेक्शन से सुरक्षित हैं। यह एक खतरनाक भ्रांति है। ये फ़ंक्शन सभी प्रकार के हमलों से रक्षा नहीं करते, विशेष रूप से LIKE, ORDER BY और LIMIT के साथ काम करते समय।
समस्या: mysqli_real_escape_string() फ़ंक्शन LIKE ऑपरेटर (जैसे % और _) के लिए कैरेक्टर को एस्केप नहीं करता। यदि आप LIKE में उपयोगकर्ता इनपुट डालते हैं, तो एक हमलावर उस डेटा तक पहुँच सकता है जिसे उसे नहीं देखना चाहिए।
कमजोरी का उदाहरण:
\n<?php\n$search = $_GET['q'];\n$safe = mysqli_real_escape_string($conn, $search);\n$query = "SEL 
