راه‌اندازی حرفه‌ای WSL2 برای توسعه
11 دقیقه مطالعه
نصب WSL2، انتخاب توزیع، .wslconfig، Git، VS Code Remote و عادت‌های حرفه‌ای برای محیط توسعه لینوکس روی ویندوز.
نصب پیش‌فرض WSL کافی است که یک shell اوبونتو باز شود؛ برای کار روزانهٔ جدی باید حافظه، محل پروژه، Git، ادیتور و به‌روزرسانی را از روز اول درست بچینید. این مقاله مسیر حرفه‌ای را از نصب تا چک‌لیست هفتهٔ اول می‌دهد تا بعداً با دیسک پر، بیلد کند و پیکربندی گم‌شده نجنگید.
پاسخ کوتاه
در PowerShell با دسترسی Administrator فرمان wsl --install را اجرا و در صورت نیاز سیستم را ری‌استارت کنید. با wsl -l -v نسخهٔ ۲ بودن توزیع را تأیید کنید. پروژه را زیر فایل‌سیستم لینوکس نگه دارید، VS Code را با Remote - WSL وصل کنید، فایل .wslconfig را برای سقف RAM و CPU بگذارید، و wsl --update را بخشی از نگهداری کنید.
محیط خوب WSL یعنی: فایل در لینوکس، سقف منابع مشخص، ادیتور ریموت، و به‌روزرسانی منظم — نه فقط Ubuntu در Start Menu.
پیش‌نیازها
- ویندوز ۱۰ نسخهٔ ۲۰۰۴ و بالاتر (Build 19041+) یا ویندوز ۱۱ برای مسیر سادهٔ wsl --install.
- مجوز Administrator برای فعال‌سازی ویژگی‌ها.
- مجازی‌سازی فعال در BIOS/UEFI برای WSL 2.
- فضای دیسک کافی؛ توزیع و پروژه رشد می‌کنند.
نسخهٔ ویندوز را با winver چک کنید. اگر سازمانی Microsoft Store را بسته، مسیر --web-download در مستندات نصب Microsoft Learn را ببینید.
نصب پایه
powershell
wsl --install wsl --list --online wsl --install -d Ubuntu-24.04 wsl --status wsl -l -v wsl --set-default-version 2 wsl --set-version Ubuntu-24.04 2
طبق Microsoft Learn، wsl --install معمولاً اجزای لازم، هسته، پیش‌فرض WSL 2 و Ubuntu را می‌آورد. اگر فقط متن راهنما دیدید، احتمالاً WSL از قبل نصب بوده؛ با -d توزیع اضافه کنید. اگر پیشرفت نصب روی صفر می‌ماند، گزینهٔ --web-download را امتحان کنید.
کاربر لینوکس و به‌روزرسانی اولیه
اولین ورود، نام کاربری و رمز لینوکس را می‌سازد — جدا از PIN ویندوز. بلافاصله بسته‌های پایه را به‌روز کنید و با root روزانه کار نکنید.
bash
sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential git curl ca-certificates
محل پروژه: مهم‌ترین تصمیم عملکردی
فایل‌های پروژه را داخل فایل‌سیستم لینوکس نگه دارید (مثلاً ~/work/...) نه روی /mnt/c/... . دسترسی متقابل از طریق \wsl$\Distro\home\... یا از داخل لینوکس به /mnt/c ممکن است، ولی I/O سنگین بیلد روی درایو ویندوزی از WSL2 معمولاً کندتر است. مستندات setup محیط توسعهٔ Microsoft همین اصل را تأکید می‌کند.
- کد و node_modules / target / .git داخل ~ لینوکس.
- فقط خروجی‌هایی که باید با ابزار خالص ویندوز باز شوند را به سمت C: کپی یا mount کنید.
- از آنتی‌ویروس بخواهید استثنا برای مسیر VHDX/WSL بگذارد اگر اسکن باعث قفل می‌شود (سیاست سازمان).
Windows Terminal و کیفیت زندگی
پروفایل توزیع را در Windows Terminal به‌عنوان پیش‌فرض توسعه بگذارید، فونت Cascadia یا فونت Nerd مناسب، و دایرکتوری شروع را روی ~/work تنظیم کنید. کپی/پیست و Unicode در Terminal مدرن پایدارتر از کنسول قدیمی است.
.wslconfig و wsl.conf
طبق Microsoft Learn، فایل %UserProfile%\.wslconfig تنظیمات سراسری VM مربوط به WSL2 است (RAM، CPU، swap، localhostForwarding و غیره). فایل /etc/wsl.conf داخل هر توزیع برای automount، network، systemd و کاربر پیش‌فرض است. بعد از تغییر .wslconfig معمولاً wsl --shutdown لازم است تا VM از نو بالا بیاید.
ini
# %UserProfile%\.wslconfig [wsl2] memory=8GB processors=4 swap=4GB localhostForwarding=true
ini
# /etc/wsl.conf [boot] systemd=true [user] default=YOUR_LINUX_USER
سقف memory را روی لپ‌تاپ ۸–۱۶GB منطقی انتخاب کنید تا Vmmem همهٔ RAM ویندوز را نبلعد. systemd را فقط اگر به سرویس‌های واقعی داخل توزیع نیاز دارید روشن کنید و پیامد مصرف را بپذیرید.
Git: یک بار خط پایان را درست کنید
تیم‌های ترکیبی با CRLF/LF می‌سوزند. تصمیم بگیرید کجا commit می‌کنید (معمولاً داخل WSL) و core.autocrlf / .gitattributes را شفاف کنید. credential را می‌توانید با Git Credential Manager سمت ویندوز یکپارچه کنید تا PAT را دوباره تایپ نکنید — طبق راهنمای setup مایکروسافت.
bash
git config --global core.autocrlf input git config --global init.defaultBranch main
VS Code Remote - WSL
افزونهٔ Remote - WSL را نصب کنید، از داخل پوشهٔ لینوکس code . بزنید یا از Command Palette گزینهٔ Reopen in WSL را انتخاب کنید. در این حالت افزونه‌های workspace روی لینوکس نصب می‌شوند و ترمینال داخلی همان bash توزیع است. دیباگ Node/Python/Go روی فایل‌سیستم لینوکس طبیعی‌تر است.
دیتابیس، Docker و پورت
می‌توانید دیتابیس را داخل WSL، در Docker Desktop با backend WSL2، یا روی ویندوز نصب کنید. دو تا را همزمان روی یک پورت نگذارید. localhostForwarding معمولاً اجازه می‌دهد از ویندوز به سرویس گوش‌دهنده در WSL وصل شوید؛ اگر نه، آدرس واقعی را با hostname -I و فایروال چک کنید.
powershell
wsl --update wsl --shutdown wsl -l -v wsl --status
نگهداری هفته‌ای
- wsl --update برای هسته و اجزای WSL.
- apt update/upgrade داخل توزیع.
- نظارت بر فضای دیسک VHDX؛ در صورت نیاز فشرده‌سازی طبق مستند مایکروسافت.
- پشتیبان گرفتن از ~/work و فهرست بسته‌های حیاتی.
- اگر WSL قفل شد: wsl --shutdown و در موارد سخت‌تر بررسی سرویس/فرایند مرتبط.
اشتباه‌های رایج
- کل ریپو روی C:\Users\...\project و بیلد از WSL.
- نداشتن سقف memory و کند شدن کل ویندوز.
- مخلوط کردن Git ویندوز و Git لینوکس روی یک working tree بدون قرارداد.
- اجرای همیشگی با root.
- نادیده گرفتن wsl --update تا وقتی یک باگ شبکه/هسته تمام روز را بگیرد.
- نصب چند توزیع بدون نام‌گذاری و default مشخص.
چه وقت همین کافی است / چه وقت نه
برای توسعهٔ وب، اسکریپت، کانتینر سبک و ابزار یونیکس روی لپ‌تاپ ویندوزی، WSL2 حرفه‌ای‌شده معمولاً کافی است. اگر به کرنل سفارشی، لود بسیار خاص، یا جداسازی سخت نیاز دارید، VM کامل یا ماشین لینوکس جدا را ارزیابی کنید. مقالهٔ ۱۹۶ معیارهای انتخاب را باز می‌کند.
عمق عملیاتی بیشتر
توسعه روی ویندوز وقتی پایدار می‌شود که ابزار مشاهده، کنترل فرایند و زمان‌بندی را مثل مهارت کدنویسی جدی بگیرید.
بسیاری از اتلاف وقت روزانه نه از کمبود دانش زبان برنامه‌نویسی، بلکه از ندیدن مصرف حافظه، قفل فایل و سرویس خاموش است.
قبل از نصب ابزار شخص ثالث، قابلیت توکار ویندوز را امتحان کنید؛ مستندات Microsoft Learn معمولاً مسیر رسمی و پشتیبانی‌شده را نشان می‌دهد.
عادت کنید برای هر مشکل یک یادداشت کوتاه بنویسید: نشانه، زمان، PID، و فرمان یا ابزاری که استفاده کردید.
این یادداشت‌ها در تیم به پایگاه دانش تبدیل می‌شوند و از تکرار دیباگ کور جلوگیری می‌کنند.
قدرت واقعی وقتی است که Task Manager، Resource Monitor، Event Viewer و PowerShell را در یک جریان واحد به کار ببرید.
اگر فقط یک پنجره را باز می‌کنید و حدس می‌زنید، همان چرخهٔ ریبوت بی‌دلیل تکرار می‌شود.
برای کارهای تکراری، به‌جای حافظهٔ انسانی از Task Scheduler و اسکریپت نسخهٔکنترل‌شده استفاده کنید.
مجوز حداقل را رعایت کنید؛ اجرای همیشگی با Administrator ریشهٔ بسیاری از عادت‌های ناامن است.
در نهایت، محیط توسعهٔ خوب آن است که شکست را سریع دیده، محدود و قابل‌بازگشت می‌کند — نه اینکه همه چیز را هر بار از صفر نصب کنید.
وقتی اپلیکیشن پاسخ نمی‌دهد، اول صبر کوتاه و مشاهدهٔ CPU و دیسک مفیدتر از End Task فوری است؛ شاید در حال نوشتن فایل یا انتظار شبکه باشد.
Analyze wait chain در Task Manager کمک می‌کند ببینید فرایند به‌خاطر وابستگی به فرایند دیگر متوقف شده یا واقعاً حلقهٔ معیوب دارد.
Resource Monitor جزئیات دستهٔ دیسک و شبکه را نشان می‌دهد که در نمای سادهٔ Task Manager دیده نمی‌شود.
برای مصرف حافظه، تفاوت Working Set و Commit را بشناسید تا فقط با یک عدد بزرگ نترسید یا برعکس مشکل نشتی را نادیده نگیرید.
PowerShell با Get-Process و Get-Counter برای نمونه‌برداری تکرارپذیر مناسب است و خروجی‌اش را می‌توان لاگ کرد.
در محیط حرفه‌ای، ریبوت باید آخرین گزینه باشد نه اولین Reflex؛ ریبوت علت را پاک می‌کند و یادگیری را می‌کشد.
ابزارهای عیب‌یابی توکار مثل Reliability History و Windows Memory Diagnostic برای الگوی زمانی خطا ارزش دارند.
اگر مشکل بعد از به‌روزرسانی شروع شده، همبستگی تاریخ وصله با Event Log را قبل از بازنصب کامل بررسی کنید.
اسکریپت‌های نگهداری را با مسیر مطلق و حساب کم‌مجوز در Task Scheduler بگذارید و نتیجه را در فایل لاگ ببینید.
همکاری با تیم پشتیبانی وقتی سریع می‌شود که PID، نام دقیق فرایند، و اسکرین از Performance را ضمیمه کنید نه فقط «سیستم کند است».
ویندوز برای توسعه‌دهنده یک مانع نیست اگر لایهٔ مشاهده و کنترل را یاد بگیرید؛ همین مهارت‌ها روی سرور ویندوزی هم برمی‌گردد.
از طرفی، وابستگی افراطی به GUI بدون فرمان خط فرمان، خودکارسازی و CI را ضعیف می‌کند.
تعادل سالم این است: GUI برای کشف، PowerShell برای تکرار، و مستندسازی برای تیم.
در پروژه‌های چندسیستمی، مرز واضح بین ابزار ویندوز و ابزار WSL از تداخل PATH و نسخه‌های تکراری جلوگیری می‌کند.
هر ماه یک‌بار فهرست سرویس‌های غیرضروری استارت‌آپ و تسک‌های زمان‌بندی‌شده را مرور کنید؛ رشد خاموش آن‌ها منابع را می‌خورد.
نکتهٔ تکمیلی برای پایداری محیط این است که تغییرات سیستم را کوچک و قابل‌برگشت نگه دارید و همیشه مسیر بازگشت داشته باشید.
قبل از تغییر سیاست اجرا یا نصب درایور آزمایشی، یک نقطهٔ بازیابی یا حداقل یادداشت نسخهٔ قبلی ابزارها تهیه کنید.
در دیباگ شبکهٔ محلی، ابتدا از localhost و سپس از نشانی واقعی استفاده کنید تا لایهٔ مشکل جدا شود.
برای کارهای فایل حجیم، به‌جای کپی دستی تکراری از اسکریپت و لاگ استفاده کنید تا خطا قابل‌پیگیری باشد.
اگر ابزار توکار جواب نداد، آن‌گاه سراغ ابزار پیشرفته‌تر بروید؛ ترتیب مهم است چون دادهٔ اولیه را از دست نمی‌دهید.
همین ترتیب را در تیم آموزش دهید تا نیروی تازه‌وارد هم از ریبوت اول شروع نکند.
در عمل، زنجیرهٔ عیب‌یابی خوب از مشاهدهٔ زنده شروع می‌شود، به لاگ تاریخی می‌رسد، و با یک تغییر کوچک قابل‌برگشت ادامه پیدا می‌کند.
اگر در همان قدم اول نرم‌افزار را reinstall کنید، متغیرهای زیادی را همزمان جابه‌جا کرده‌اید و علت مبهم می‌ماند.
برای توسعه‌دهنده، ثبت نسخهٔ ابزار، زمان وقوع و پیام خطا بخش از کار حرفه‌ای است نه کار اضافی.
ویندوز وقتی پیش‌بینی‌پذیر می‌شود که سرویس‌ها، تسک‌های زمان‌بندی و استارت‌آپ را مثل inventory کد مدیریت کنید.
هر چه این inventory شفاف‌تر باشد، اثر جانبی آپدیت و نصب پکیج جدید کمتر غافلگیرتان می‌کند.
همچنین برای کارهای خودکار، خروجی را به فایل یا رویداد بنویسید تا موفقیت خاموش با شکست خاموش اشتباه نشود.
این عادت‌ها هزینهٔ اولیه دارند ولی در هفته‌های پرترافیک بیلد و انتشار، زمان را برمی‌گردانند.
اگر تازه‌وارد تیم هستید، همین ابزارهای توکار را در روز اول با یک سناریوی ساختگی تمرین کنید تا در حادثه واقعی دست‌پاچه نشوید.
در محیط‌هایی که هم ویندوز و هم لینوکس دارید، یک فرهنگ مشترک برای نام‌بردن فرایند، پورت و زمان رویداد بسازید.
زبان مشترک عیب‌یابی، بیشتر از یکسان‌سازی سیستم‌عامل، همکاری را سریع می‌کند.
خلاصه
راه‌اندازی حرفه‌ای WSL2 فقط install نیست: نسخهٔ ۲ را قفل کنید، پروژه را در فایل‌سیستم لینوکس بگذارید، منابع را با .wslconfig سقف بدهید، ادیتور را Remote کنید، Git و خط پایان را قرارداد کنید، و به‌روزرسانی را عادت کنید. جزئیات رفتار VM در مقالهٔ ۱۹۵ آمده است.
سوالات متداول
WSL 1 یا 2؟
برای اکثر کار توسعه امروز WSL 2 پیش‌فرض و توصیه‌شده است. WSL 1 فقط در سناریوهای خاص فایل‌سیستم متقابل ممکن است مطرح شود.
چطور توزیع را عوض کنم؟
با wsl --set-default Name و برای اجرا بدون تغییر پیش‌فرض: wsl -d Name.
آیا Docker جدا لازم است؟
اگر به Docker نیاز دارید، Docker Desktop با WSL2 engine رایج است؛ یا موتور داکر داخل خود توزیع — یکی را انتخاب و مستند کنید.
systemd را همیشه روشن کنم؟
فقط اگر به واحدهای systemd واقعی نیاز دارید. هزینهٔ منابع و پیچیدگی بوت را بسنجید.
منابع و مراجع
- Install WSL — Microsoft Learn: https://learn.microsoft.com/en-us/windows/wsl/install
- Set up a WSL development environment — Microsoft Learn: https://learn.microsoft.com/en-us/windows/wsl/setup/environment
- Advanced settings configuration in WSL (.wslconfig / wsl.conf) — Microsoft Learn: https://learn.microsoft.com/en-us/windows/wsl/wsl-config
- Basic commands for WSL — Microsoft Learn: https://learn.microsoft.com/en-us/windows/wsl/basic-commands
نویسنده
سا
سهیل ابراهیم‌پور بنیان‌گذار FutureForge است. روی طراحی محصول، معماری و استقرار نرم‌افزار سفارشی کار می‌کند.
یادداشت‌های مرتبط
برای انتخاب مسیر فنی پروژه‌تان کمک می‌خواهید؟
از مسئله و محدودیت‌هایتان بگویید؛ اگر بتوانیم همراهی‌تان کنیم، برای گفت‌وگو هماهنگ می‌کنیم.
