Debug 和 Release 並沒有本質的區別，他們只是VC預定義提供的兩組編譯選項的集合，編譯器只是按照預定的選項行動。如果我們願意，我們完全可以把Debug和Release的行爲完全顛倒過來。當然也可以提供其他的模式，例如自己定義一組編譯選項，然後命名爲MY_ABC等。習慣上，我們仍然更願意使用VC已經定義好的名稱。
Debug版本包括調試信息，所以要比Release版本大很多（可能大數百K至數M）。至於是否需要DLL支持，主要看你採用的編譯選項。如果是基於ATL的，則Debug和Release版本對DLL的要求差不多。如果採用的編譯選項爲使用MFC動態庫，則需要MFC42D.DLL等庫支持，而Release版本需要MFC42.DLL支持。Release不對源代碼進行調試，不考慮MFC的診斷宏，使用的是MFC Release庫，編譯時對應用程序的速度進行優化，而Debug則正好相反，它允許對源代碼進行調試，可以定義和使用MFC的 診斷宏，採用MFC Debug庫，對速度沒有優化。
既然Debug和Release僅僅是編譯選項的不同，那麼爲什麼要區分Debug和Release版本呢？
Debug和Release，在我看來主要是針對其面向的目標不同的而進行區分的。Debug通常稱爲調試版本，通過一系列編譯選項的配合，編譯的結果通常包含調試信息，而且不做任何優化，以爲開發人員提供強大的應用程序調試能力。而Release通常稱爲發佈版本，是爲用戶使用的，一般客戶不允許在發佈版本上進行調試。所以不保存調試信息，同時，它往往進行了各種優化，以期達到代碼最小和速度最優。爲用戶的使用提供便利。
下面僅就默認的Debug和Release版本的選項進行 比較，詳細的編譯選項可以看MSDN的說明。
我們將默認的Debug和Release的選項設置進行比較，過濾掉相同設置，主要的不同如下：
編譯選項：/Od /D "_DEBUG" /Gm /RTC1 /MDd /Fo"Debug““" /ZI
鏈接選項：/OUT："D：“MyProject“logging“Debug“OptionTest.dll" /INCREMENTAL
Release設置：
編譯選項：/O2 /GL /D "NDEBUG" /FD /MD /Fo"Release““" /Zi
鏈 接選項：/OUT："D：“MyProject“logging“Release“OptionTest.dll" /INCREMENTAL：NO
Debug 版本：
/MDd /MLd 或 /MTd使用 Debug runtime library(調試版本的運行 時刻函數庫)
/Od 關閉優化開關
/D "_DEBUG" 相當於 #define _DEBUG,打開編譯調試代碼 開關(主要針對assert函數)
/ZI 創建 Edit and continue數據庫，在調試 過程中如果修改了源代碼不需重新編譯
/GZ 可以幫助捕獲內存錯誤
/Gm 打開最小化重鏈接開關，減少鏈接時 間
Release 版本：
/MD /ML 或 /MT使用發佈版本的運行時刻函數庫
/O1 或 /O2優 化開關，使程序最小或最快
/D "NDEBUG" 關閉條件編譯調試代碼開關(即不編譯assert函數)
/GF 合併重 復的字符串，並將字符串常量放到只讀內存，防止被修改
MDd與MD
首先，Debug版本使用調試版本的運行時庫（/MDd選項），Relase版本則使用的是發佈版本的運行時庫（vcrt.dll）。其區別主要在於運行時的性能影響。調試版本的運行時庫包含了調試信息，並採用了一些保護機制以幫助發現錯誤，也因此，其性能不如發佈版本。編譯器提供的Runtime Library很穩定，不會造成Release版本錯誤，倒是由於Debug版本的Runtime Library加強了對錯誤的檢測，如堆內存分配檢查等，反而會報告錯誤，應當指出，如果Debug有錯誤，而Release版本正常，程序肯定是有Bug的，只是我們還沒有發現。
ZI與Zi
其次，/ZI選項與/Zi選項。通過使用/ZI選項，可以在調試過程修改代碼 而不需要重新編譯。這是個調試的好幫手，可如果我們使用Release版本，這將變得不可行。
Od與O2
/O2與/Od選項：Od是關閉編譯器優化，普遍用於Debug版本。而O2選項是創建最快速代碼，這當然是Release版本的不二選擇。
RTCx選 項
/RTCx選項讓編譯器插入動態檢測代碼以幫助你檢測程序中的錯誤。比如，它會將局部變量初始化爲非零值。包括用0xCC初始化所有自動變量，0xCD初始化堆中分配的內存（即new的內存），使用0xDD填充被釋放的內存（即delete的內存），0xFD初始化受保護的內存（debug版在動態分配內存的前後加入保護內存以防止越界訪問）。這樣做的好處是這些值都很大，一般不可能作爲指針，考試，大提示作爲數值也很少用到，而且這些值很容易辯認，因此有利於在Debug版本中發現Release版纔會遇到的錯誤。另外，通過函數指針調用函數時，會通過檢查棧指針驗證函數調用的匹配性（防止原型不匹配）。使用/RTCx選項會造成Debug版本出錯，而Release版本正常的現象，因爲Release版中未初始化的變量是隨機的，很可能使指針指向了有效但是錯誤的地址，從而掩蓋了錯誤。這個編譯選項只能在/Od選項下使用。
Gm，INCREMENTAL or NO
編譯選項中的Gm和鏈接選項中的INCREMENTAL都只爲一個目的，加快編譯速度。我們經常遇上這樣的問題，只修改了一個頭文件，結果卻造成所有動態庫的重新編譯。而這兩個選項就是爲了解決這樣的問題。如果啓用了/Gm開關，編譯器在項目中的.idb文件中存儲了源文件和類定義之間的依賴關係。之後的編譯過程中使用.idb文件中的信息確定是否需要編譯某個源文件，哪怕是此源文件已經包含了已修改的.h文件。
INCREMENTAL開關默認是開啓的。使用增量鏈接生 成的可執行文件或者動態鏈接庫會大於非增量鏈接的程序，因爲有代碼和數據的填充。另外，增量鏈接的文件還包含跳轉trunk以處理函數重定位到新地址。
MSDN 上明確指出：爲確保最終發佈版本不包含填充或者trunk，請非增量鏈接程序。
/GZ 選項：做以下這些事
1.初 始化內存和變量。包括用 0xCC初始化所有自動變量，0xCD ( Cleared Data )初始化堆中分配的內存（即動態分配 的內存，例如 new），0xDD ( Dead Data )填充已被釋放的堆內存（例 如 delete），0xFD( deFencde Data )初始化受保護的內存（debug版在動態分配內存的前後加入保護內存以防止越界訪問），其中括號中的詞是微軟建議的助記詞。這樣做的好處是這些值都很大，作爲指針是不可能的（而且32 位系統中指針很少是奇數值， 在有些系統中奇數的指針會產生運行時錯誤），作爲數值也很少遇到，而且這些值也很容易辨認，因此這很有利於在Debug 版中發 現Release 版纔會遇到的錯誤。要特別注意的是，很多人認爲編譯器會用0 來初始化變量，這是錯誤的（而且這樣很不利於查找錯 誤）。
2. 通過函數指針調用函數時，會通過檢查棧指針驗證函數調用的匹配性。（防止原形不匹配）
3. 函數返回前檢查 棧指針，確認未被修改。（防止越界訪問和原形不匹配，與第二項合在一起可大致模擬幀指針省略FPO ）
通常 /GZ 選 項會造成Debug 版出錯而Release 版正常的現象，因爲Release 版中未初始化的變量是隨機的，這有可能使指針指向一 個有效地址而掩蓋了非法訪問。
_DEBUG與NDEBUG
這是最重要的一個選項。這兩個是編譯器的預處理器定義，默認情況下_DEBUG用於Debug版本，而NDEBUG用於Release版本。 它們可以說是重要的無以復加。因爲，assert系列的斷言僅僅在_DEBUG下生效！
下面是assert.h文件中摘出來的：
C++代碼
可以看出在未定義_DEBUG時，assert變成一條空語句不被執行。
也就是說，我們現在所有發佈的版本無法使 用斷言機制進行程序調試。
相關經驗：
1. 變量。
大家都知道，debug跟release在初始化變量時所做的操作是不同的，debug是將每個字節位都賦成0xcc，而release的賦值近似於隨機。如果你的程序中的某個變量沒被初始化就被引用，就很有可能出現異常：用作控制變量將導致流程導向不一致；用作數組下標將會使程序崩潰；更加可能是造成其他變量的不準確而引起其他的錯誤。所以在聲明變量後馬上對其初始化一個默認的值是最簡單有效的辦法，否則項目大了你找都沒地方找。代碼存在錯誤在debug方式下可能會忽略而不被察覺到。debug方式下數組越界也大多不會出錯，在release中就暴露出來了，這個找起來就比較難了。
2. 自定義消息的消息參數。
MFC爲我們提供了很好的消息機制，更增加了自定義消息，好處我就不用多說了。這也存在debug跟release的問題嗎？答案是肯定的。在自定義消息的函數體聲明時，時常會看到這樣的寫法：afx_msg LRESULT OnMessageOwn(); Debug 情況下一般不會有任何問題，而當你在Release下且多線程或進程間使用了消息傳遞時就會導致無效句柄之類的錯誤。導致這個錯誤直接原因是消息體的參數沒有添加，即應該寫 成：afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam); 3. release模式下不出錯，但debug模式下報錯。
這種情況下大多也是因爲代碼書寫不正確引起的，查看MFC 的源碼，可以發現好多ASSERT的語句(斷言)，這個宏只是在debug模式下才有效，那麼就清楚了，release版不報錯是忽略了錯誤而不是沒有錯誤，這可能存在很大的隱患，因爲是Debug模式下，比較方便調試，好好的檢查自己的代碼，再此就不多說了。
3. ASSERT, VERIFY, TRACE.......... 調試宏
這種情況很容易解釋。舉個例子：請在VC下輸入ASSERT然後選中按F12跳到宏定義的地方，這裏你就能夠發現Debug中ASSERT要執行AfxAssertFailedLine，而Release下的宏定義卻爲\"#define ASSERT(f) ((void)0)\"。所以注意在這些調試宏的語句不要用程序相關變量如i++寫操作的語句。
VERIFY 是個例外，\"#define VERIFY(f) ((void)(f))\"，即執行。
哪些情況下Release版會出錯？
1. Runtime Library：鏈接哪種運行時刻函數庫通常只對程序的性能產生影響。調試版本 的 Runtime Library 包含了調試信息，並採用了一些保護機制以幫助發現錯誤，因此性能不如發佈版本。編譯器提供 的Runtime Library 通常很穩定，不會造成Release 版錯誤；倒是由 於Debug 的Runtime Library 加強了對錯誤的檢測，如堆內存分配，有時會出現Debug 有錯 但Release 正常的現象。應當指出的是，如果Debug 有錯，即使Release 正常，程序肯定是有Bug 的，只不 過可能是Release 版的某次運行沒有表現出來而已。
2. 優化：這是造成錯誤的主要原因，因爲關閉優化時源程序基本上是直接翻譯的，而打開優化後編譯器會作出一系列假設。這類錯誤主要有以下幾種：
(1) 幀指針 (Frame Pointer)省略（簡稱FPO ）：在函數調用過程中，所有調用信息（返回地址、參數）以及自動變量都是放在棧中的。若函數的聲明與實現不同（參數、返回值、調用方式），就會產生錯誤，但Debug 方式下，棧的訪問通過EBP 寄存器保存的地址實現，如果沒有發生數組越界之類的錯誤（或是越界“不多”），函數通常能正常執行；Release方式下，優化會省略 EBP棧基址指針，這樣通過一個全局 指針訪問棧就會造成返回地址錯誤是程序崩潰。C++的強類型特性能檢查出大多數這樣的錯誤，但如果用了強制類型轉換，就不行了。你可以 在 Release 版本中強制加入/Oy- 編譯選項來關掉幀指針省略，以確定是否此類錯誤。此類錯誤通常有：
MFC消息響應函數書寫錯誤。正確的應爲
afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam);
ON_MESSAGE 宏 包含強制類型轉換。防止這種錯誤的方法之一是重定義 ON_MESSAGE宏，把下列代碼加到 stdafx.h中 （在#include "afxwin.h"之後）,函數原形錯誤時編譯會報錯
C++代碼
(2) volatile 型變量：volatile告訴編譯器該變量可能被程序之外的未知方式修改（如系統、其他進程和線程）。優化程序爲了使程序性能提高，常把一些變量放在寄存器中（類似於register 關鍵字），而其他進程只能對該變量所在的內存進行修改，而寄存器中的值沒變。如果你的程序是多線程的，或者你發現某個變量的值與預期的不符而你確信已正確的設置了，則很可能遇到這樣的問題。這種錯誤有時會表現爲程序在最快優化出錯而最小優化正常。把你認爲可疑的變量加上volatile 試試。
(3) 變量優化：優化程序會根據變量的使用情況優化變量。例如，函數中有一個未被使用的變量，在 Debug 版中它有可能掩蓋一個數組越界，而在Release 版中，這個變量很可能被優化調，此時數組越界會破壞棧中有用的數據。當然，實際的情況會比這複雜得多。與此有關的錯誤有：
非法訪問，包括數組越界、指針錯誤 等。例如
C++代碼
j 雖然在數組越界時已出了作用域，但其空間並未收回，因而i 和j 就會掩蓋越界。而Release 版由於i、j並未其很大作用可能會被優化掉，從而使棧被破壞。
3. _DEBUG 與 NDEBUG：當定義了 _DEBUG時，assert()函數會被編譯， 而 NDEBUG時不被編譯。除此之外，VC++中還有一系列斷言宏。這包括：
ANSI C 斷 言 void assert(int expression );
C Runtime Lib 斷 言 _ASSERT( booleanExpression );
_ASSERTE( booleanExpression );
MFC 斷 言 ASSERT( booleanExpression );
VERIFY( booleanExpression );
ASSERT_VALID( pObject );
ASSERT_KINDOF( classname, pobject );
ATL 斷 言 ATLASSERT( booleanExpression );
此外，TRACE() 宏的編譯也受_DEBUG 控 制。
所有這些斷言都只在 Debug版中才被編譯，而在Release 版中被忽略。唯一的例外 是VERIFY() 。事實上，這些宏都是調用了assert() 函數，只不過附加了一些與庫有關的調試代碼。如果你在這些宏中加入了任何程序代碼，而不只是布爾表達式（例如賦值、能改變變量值的函數調用 等），那麼Release 版都不會執行這些操作，從而造成錯誤。初學者很容 易犯這類錯誤，查找的方法也很簡單，因爲這些宏都已在上面列出，只要利用VC++ 的Find in Files 功能在工程所有文件中 找到用這些宏的地方再一一檢查即可。另外，有些高手可能還會加入#ifdef _DEBUG 之類的條件編譯，也要注意一下。
順便值 得一提的是 VERIFY() 宏，這個宏允許你將程序代碼放在布爾表達式裏。這個宏通常用來檢查Windows API 的返回值。有些人 可能爲這個原因而濫用VERIFY() ，事實上這是危險的，因爲VERIFY() 違反了斷言的思想，不能使程序代碼和調試代碼完全分離， 最終可能會帶來很多麻煩。因此，專家們建議儘量少用這個宏。
一、"Debug是調試版本，包括的程序信息更多"
補充：只有DEBUG版的程序才能設置斷點、單步執行、使用TRACE/ASSERT等調試輸出語句。REALEASE不包含任何調試信息，所以體積小、運行速度快。
I. 內存分配問題
1. 變量未初始化。下面的程序在debug中運行的很好。
C++代碼
而在release中卻不行，因爲debug中會自動給變量初始化found=FALSE,而在release版中則不會。所以儘可能的給變量、類或結構 初始化。
2. 數據溢出的問題
如：
C++代碼
44 char buffer[10];
45 int counter;
46 lstrcpy(buffer, "abcdefghik");
在debug版中buffer的NULL覆蓋了counter的高位，但是除非counter>16M,什麼問題也沒有。但是在release版中，counter可能被放在寄存器中，這樣NULL就覆蓋了buffer下面的空間，可能就是函數的返回地址，這將導致ACCESS ERROR。
3. DEBUG版和RELEASE版的內存分配方式是不同的 。如果你在DEBUG版中申請ele 爲6*sizeof(DWORD)=24bytes,實際上分配給你的是32bytes（debug版以32bytes爲單位分配）， 而在release版，分配給你的就是24bytes（release版以8bytes爲單位），所以在debug版中如果你寫ele[6],可能不會有什麼問題，而在release版中，就有ACCESS VIOLATE。
II. ASSERT和VERIFY
1. ASSERT在Release版本中是不會被編譯的。
ASSERT宏是這樣定義的
C++代碼
47
48 #ifdef _DEBUG
49 #define ASSERT(x) if( (x) == 0) report_assert_failure()
50 #else
51 #define ASSERT(x)
52 #endif
實際上覆雜一些，但無關緊要。假如你在這些語句中加了程序中必須要有的代碼
比如
C++代碼
53
54 ASSERT(pNewObj = new CMyClass);
55
56 pNewObj->MyFunction();
這種時候Release版本中的pNewObj不會分配到空間
所以執行到下一個語句的時候程序會報該程序執行了非法操作的錯誤。這時可以用VERIFY：
C++代碼
57
58 #ifdef _DEBUG
59 #define VERIFY(x) if( (x) == 0) report_assert_failure()
60 #else
61 #define VERIFY(x) (x)
62 #endif
這樣的話，代碼在release版中就可以執行了。
III. 參數問題：
自定義消息的處理函數，必須定義如下：
afx_msg LRESULT OnMyMessage(WPARAM, LPARAM);
返回值必須是HRESULT型，否則Debug會過，而Release出錯
IV. 內存分配
保證數據創建和清除的統一性：如果一個DLL提供一個能夠創建數據的函數，那麼這個DLL同時應該提供一個函數銷燬這些數據。數據的創建和清除應該在同一 個層次上。
V. DLL的災難
人們將不同版本DLL混合造成的不一致性形象的稱爲“動態連接庫的地獄“(DLL Hell)，甚至微軟自己也這麼說 http://msdn.microsoft.com/library/techart/dlldanger1.htm)。
如果你的程序使用你自己的DLL時請注意：
1. 不能將debug和release版的DLL混合在一起使用。debug都是debug版，release版都是release版。
解決辦法是將debug和release的程序分別放在主程序的debug和release目錄下
2. 千萬不要以爲靜態連接庫會解決問題，那隻會使情況更糟糕。
VI. RELEASE版中的調試 ：
1. 將ASSERT()改爲 VERIFY()。找出定義在"#ifdef _DEBUG"中的代碼，如果在RELEASE版本中需要這些代碼請將他們移到定義外。查找TRACE(...)中代碼，因爲這些代碼在RELEASE中也不被編譯。 請認真檢查那些在RELEASE中需要的代碼是否並沒有被便宜。
2. 變量的初始化所帶來的不同，在不同的系統，或是在DEBUG/RELEASE版本間都存在這樣的差異，所以請對變量進行初始化。
3. 是否在編譯時已經有了警告?請將警告級別設置爲3或4,然後保證在編譯時沒有警告出現.
VII. 將Project Settings"中 "C++/C "項目下優化選項改爲Disbale（Debug）。編譯器的優化可能導致許多意想不到的錯誤，請參http://www.pgh.NET /~newcomer/debug_release.htm
1. 此外對RELEASE版本的軟件也可以進行調試，請做如下改動：
在"Project Settings"中"C++/C"項目下設置"category"爲"General"並且將"Debug Info"設置爲"Program Database"。
在"Link"項目下選中"Generate Debug Info"檢查框。
"Rebuild All"
如此做法會產生的一些限制：
無法獲得在MFC DLL中的變量的值。必須對該軟件所使用的所有DLL工程都進行改動。
另：
1. MS BUG：MS的一份技術文檔中表明，在VC5中對於DLL的"Maximize Speed"優化選項 並未被完全支持，因此這將會引起內存錯誤並導致程序崩潰。
2. http://www.sysinternals.com/有一個程序DebugView，用來捕捉OutputDebugString的輸出，運行起來後（估計是自設爲system debugger）就可以觀看所有程序的OutputDebugString的輸出。此後，你可以脫離VC來運行你的程序並觀看調試信息。
3. 有一個叫Gimpel Lint的靜態代碼檢查工具，據說比較好用http://www.gimpel.com/不過要化$的。
Debug與Release不同的問題在剛開始編寫代碼時會經常發生，99%是因爲你的代碼書寫錯誤而導致的，所以不要動不動就說系統問題或編譯器問題，努力找找自己的原因纔是根本。我從前就常常遇到這情況，經歷過一次次的教訓後我就開始注意了，現在我所寫過的代碼我已經好久沒遇到這種問題了。下面是幾個避免的方面，即使沒有 這種問題也應注意一下：
1. 注意變量的初始化，尤其是指針變量，數組變量的初始化(很大的情況下另作考 慮了)。
2. 自定義消息及其他聲明的標準寫法
3. 使用調試宏時使用後最好註釋掉
4. 儘量使用 try - catch(...)
5. 儘量使用模塊，不但表達清楚而且方便調試。