解惑小生

執行緒同步 9：死鎖問題

Wed, 04 Mar 2026 22:04:36 +0800

這次要介紹的是死鎖。聽到這名字，會不會讓人以為又是具有某種特殊性質的執行緒鎖？不，死鎖並不是一種執行緒鎖，而是一種我們並不樂見的情況……

情境

在真正開始之前，先讓我們看一段程式範例。這個範例取材自我自己的程式專案，不過經過了非常用力的刪減修改，基本只保留了用來呈現死鎖問題的最核心部份。程式碼雖然以 C++ 語法撰寫，但因為這次的範例並不是一個完整可編譯執行的程式，因此也可以把它看作是虛擬碼，應將重點放在理解而非測試。

我建立了一個叫作 Logger 的軟體模組，它被設計用來將程式運作時所發生的各種事情記錄在一個文字檔內，供後續需要時可以人工追查程式運作中曾經歷過的事情。所以在整個程式的程式碼各處都會呼叫 WriteLogger() 函式，目的是將當下所產生的訊息記錄傳送給 Logger 模組，讓它將記錄以某種格式編碼為一段文字之後寫入檔案儲存。其中將記錄轉換為文字訊息的部份還提供了幾種不同的格式可供使用者依據喜好需求而做選用，在 Logger 內以一個整數旗標用來表示使用者所偏好的格式 ID。最後，這個 Logger 還可以讓使用者在任何時候變更有關的設定參數，無論是編碼格式或甚可能是想要更改記錄檔的檔名或存放位置等都可以，只要呼叫 ReloadLogger() 就能夠變更 Logger 的設定配置。並且修改這些配置和程式正常的訊息記錄動作並不互相衝突，使用者完全可以在程式運作的任何階段去呼叫 ReloadLogger() 修改配置，並且同時可能隨時也都有人正在呼叫 WriteLogger() 函式；一邊正在儲存程式記錄而另一邊同時可以修改配置，並且變更後的配置可以立刻生效，變更後的下一筆寫入就會立刻套用新的設定來編碼和寫檔。最後當然，這些函式可能在程式的任何地方、任何執行緒裡被呼叫，因此對執行緒的衝突保護也是必須實現的部份，並且本篇的重點也就在這上面。

解說完了這個 Logger 模組的功能後，現在讓我們來看看這個模組的程式碼。首先先來看看 Logger 的資料結構：

struct Logger
{
    Mutex conf_mutex;   // 用來保護 name 和 mode 的互斥子
    string name;
    int mode;

    Mutex file_mutex;   // 用來保護 file 的互斥子
    File file;
}

Logger 資料結構裡面最核心的就只有 3 個東西，一個真正用來寫檔案的檔案物件 file，可能是 C 語言裡面的 FILE*，或者 C++ 裡面的 std::fstream，或其它；另兩個則是記錄當前寫檔檔案名稱的 name，以及當下所使用的訊息編碼方式 mode；至於剩下兩個則是用來在多緒使用環境下做衝突保護的互斥子，想必對於本系列讀者來說應該已經很熟悉了。

接下來看看用來給使用這呼叫並將資訊給寫入檔案的 WriteLogger() 函式：

void WriteLogger(Logger &data, Record rec)
{
    data.file_mutex.Lock();

    // 如果不是已開檔狀態的話就在這裡開檔
    if(!data.file.IsOpened())
    {
        data.conf_mutex.Lock();
        data.file.Open(data.name);
        data.conf_mutex.Unlock();
    }

    // 將傳入的資料以某種方式編碼成文字並寫入檔案
    string msg = rec.Encode(data.mode);
    data.file.Write(msg);

    data.file_mutex.Unlock();
}

在通常的情況下，這函式一進來就會上鎖 file_mutex 互斥子以保護接下來要操作的 file 物件，然後將函式傳入的訊息編碼程文字，然後將文字寫入檔案，解鎖互斥子並離開，一氣呵成。不過偶有時候函式一進來會發現其實還沒開檔，這可能是因為這是程式執行以來第一次呼叫這函式，也有可能是因為剛才被修改了配置而被關了檔。然而不論何種原因，這裡如果發現檔案未開的話，那就把它打開，這樣後續才能正常寫檔。而為了避免在開檔的過程當中正好碰上其它人正在修改設定，讓我們可能剛剛好拿到才被改到一半的檔名，從而造成後續的錯誤，因此在開檔的過程中需要上鎖用來保護配置相關變數的 conf_mutex 互斥子。至於我們在編碼文字的時候索取用的那個 mode 變數則不需要上鎖保護，原因如前篇讀寫鎖所解釋，我們並不需要擔心 mode 被改到一半被我們讀取的問題。

接下來看最後一個函式，就是用來讓使用者中途變更 Logger 配置的 ReloadLogger() 函式：

void ReloadLogger(Logger &data, string name, int mode)
{
    data.conf_mutex.Lock();

    // 對於能直接簡單覆寫的數值就直接覆寫
    data.mode = mode;

    // 檔名的變更就不是只簡單複寫就完事了。
    // 如果原來的檔案物件已經處於開啟狀態的話，
    // 就需要關閉再重開，才能讓後續寫入的資料被寫到新檔案去。
    if( data.name != name )
    {
        data.name = name;

        data.file_mutex.Lock();

        if(data.file.IsOpened())
            data.file.Close();

        data.file_mutex.Unlock();
    }

    data.conf_mutex.Unlock();
}

作為設計用來修改配置的函式，一進來就上鎖了 conf_mutex 互斥子，合情合理。既然互斥子上鎖了，那接下來自然就是直接修改用來記錄配置的那些變數了。編碼代號的部份無需多加擔憂，只要變數直接覆寫就好，但是檔案名稱的變更就不一樣了。直接覆蓋檔名變數的話，如果檔案物件已經開啟，那後續呼叫 WriteLogger() 時資料依然會寫到舊檔案去，而不是寫到新檔案。因此當檔名需要更動的時候，這裡就順手將檔案物件給關了，這樣後面再呼叫 WriteLogger() 的時候自然就會用新的檔名重新開檔一次；而當然，在做這個關檔操作的時候需要上鎖 file_mutex 互斥子，以免同時剛好就遇到有其他人正在寫檔。

死鎖問題

介紹完這個範例程式之後，不知道有沒有眼尖的讀者已經發現問題？範例程式裡使用了兩個互斥子來分別保護 Logger 內的各變數，因此 Logger 的函式在多緒隨意呼叫的情況下都不會產生資料衝突的問題；但是在一個相當湊巧的機會下，程式卡死了！

當有人呼叫 ReloadLogger() 變更配置參數，並且需要變更存檔的檔名，於是就如同我們所預期的那樣，函式會走到要上鎖 file_mutex 的那一步。然而不巧，此時正好有另一條執行緒正好呼叫了 WriteLogger() 要寫檔，所以 file_mutex 一時被它給佔用了，得等。一般來說這並不是個問題，因為等它寫完檔後自然就會釋放 file_mutex 互斥子；然而這次不一樣，這次的檔案物件已經是處在關閉的狀態！

可能因為這剛好是程式啟動之後第一次呼叫 WriteLogger()，也可能是自從上次呼叫 ReloadLogger() 而關檔過後到現在正好沒有人呼叫 WriteLogger() 來寫檔，於是檔案物件一直都還是處於關閉的狀態。然而無論如何，現在 ReloadLogger() 正在等待上鎖 file_mutex 互斥子，而 WriteLogger() 則剛好正在等待上鎖 conf_mutex 互斥子；然而 conf_mutex 已經被 ReloadLogger() 給鎖定了，所以除非等到 ReloadLogger() 結束離開，否則 WriteLogger() 必須得等在那。那麼 ReloadLogger() 是什麼情況呢？ ReloadLogger() 也在等待一個已經被 WriteLogger() 給佔住的 file_mutex 互斥子。這下可好了，兩人都在等待一個被對方押著的互斥子，並且雙方都已經卡在那裡等待了，誰也不可能有機會釋放自己持有的互斥鎖。於是兩條執行緒就這樣互相等到天荒地老永遠不會回來，而這就是我們所謂的「死鎖」(Dead Lock)狀態！

當死鎖發生，這兩個執行緒就卡死在那裡永遠不可能再前進一步。然後這時也許可能又有第三條執行緒呼叫了一個簡單的函式，比如說可能是一個簡單的用來取得當前檔案名稱的函式：

string GetLoggerName(Logger &data)
{
    data.conf_mutex.Lock();
    string name = data.name;
    data.conf_mutex.Unlock();

    return name;
}

如此簡單的一個函式，也不需要上鎖兩個互斥子，只需要在取得檔名的時候暫時鎖上 conf_mutex 就好了，然而 conf_mutex 卻已經被僵持的兩個執行緒給佔住永不釋放。得，這呼叫 GetLoggerName() 的第三個執行緒也跟著卡死了，死鎖問題於是擴大！

為什麼需要多鎖？

導致死鎖問題發生的根本原因來自於使用了多個互斥子。因為需要同時鎖定兩個以上的互斥子，這才給予「雙方同時佔住一個鎖並要求等待被對方佔住的鎖」這樣的情況的發生機會；而如果我們只使用一個互斥子，自然就不會產生這種互相佔鎖的問題。然而進一步我們就要問，為什麼會需要使用多個互斥子呢？只使用一個互斥子有什麼問題嗎？回顧上面的範例，Logger 內使用了 conf_mutex 和 file_mutex 兩個互斥子，而如果我們改為只使用一個互斥子，遇到什麼需要的情況就鎖定這個互斥子就好，那麼死鎖的問題就迎刃而解！然而，採用多個互斥子所為何事呢？

通常使用多個互斥子的目的是為了提升性能。同樣以前面範例為例，若只使用一個互斥子，那麼無論是 WriteLogger() 還是 ReloadLogger() 的平均等待時間都將會延長。當呼叫 ReloadLogger() 的時候，可能只是單純改個編碼選項而已，然而如果正好碰上 WriteLogger() 正在工作的話，就會需要等待它完成才能成功上鎖互斥子；同樣當呼叫 WriteLogger() 的時候正好碰上 ReloadLogger() 正在修改設定的話，也會需要先等待它完成，即便可能兩個函式需要操作的物件並不重疊卻仍然需要等待。那麼至此這個 Logger 之所以要設計使用兩個互斥子的目的就浮現出來了。假設在實際的使用情境中，大部份的 WriteLogger() 呼叫其實可能並不會碰上需要重開檔案的機會，而大部份的 ReloadLogger() 呼叫也多半僅僅只是改變編碼選項而已，那麼把兩種資源分開來使用兩個互斥子來分別做保護的話，就可以讓兩個函式僅僅只鎖定其中一個互斥子就好。如此這兩個函式的運作就不會受到彼此的影響，無需要去等待和鎖定那些保護著自己其實並不需要的資源的互斥子。這樣一來，兩個函式在大部份的情況下都能夠順暢的各自工作而不需不必要的卡來卡去。只有在少部份的情況下才會真正需要操作使用更多的受保護資源，例如在本例中就是像在呼叫 ReloadLogger() 修改檔名時正好碰上 WriteLogger() 也正在寫檔的情況，這時才會真的需要同時鎖上兩個互斥子；只不過這只是預期中的少數需要消耗比較多等待時間的時機，而對於平均大部份情況來說是不受影響的。

這就是為什麼在實際的程式設計中常常總是免不了需要使用多個互斥子的關係，主要就是為了減少不必要的鎖定等待以提升整體性能。而當然，隨著互斥子的使用數量增加，也就給予死鎖問題能夠產生的前置條件。

鎖定順序

在了解採用多互斥子的目的之後，想必已經明白將多個互斥鎖合併為一個雖然確實可以避免問題，但並不實際。在現實的程式設計裡，主要的解決方案是採用統一的鎖定順序來避免死鎖的發生。

死鎖情況能夠發生的條件就是兩個(或以上)執行緒分別佔住了對方需要的互斥子。比如兩條執行緒都需要鎖定 A、B 兩個互斥子，第一條執行緒先鎖定 A 再鎖定 B，而第二條執行緒則先鎖定 B 再鎖定 A，那麼恭喜，這兩條執行緒總會有機會能卡死在一起！那如果調整一下鎖定的順序呢？兩條執行緒都需要鎖定 A、B 兩個互斥子，並且我們讓它們都先鎖定 A 再鎖定 B，你看這樣死鎖是不是就沒有機會發生了？這就是通常解決死鎖問題的方法。

理論上統一了互斥子的鎖定順序就可以解決問題，然而實際落實到程式設計仍有許多需要參酌考量的因素。例如以本篇的範例程式來說，如果我們規定必需要遵循的鎖定順序是先 conf_mutex 再 file_mutex，那麼 WriteLogger() 函式就需要修改為像下面這樣 (至於 ReloadLogger() 則不需要更動)：

void WriteLogger(Logger &data, Record rec)
{
    // 雖然只有在檔案物件未開啟的情況下才需要鎖定這個互斥子，
    // 但是因為要求的鎖定順序的關係，
    // 因此不論後面需要不需要，
    // 這裡都要先鎖定 conf_mutex 互斥子。
    data.conf_mutex.Lock();

    // 作為一個設計用來寫檔的函式，
    // 本來就需要鎖定 file_mutex 互斥子。
    data.file_mutex.Lock();

    if(!data.file.IsOpened())
        data.file.Open(data.name);

    // 到這裡確定後面不再需要 conf_mutex 互斥子了，
    // 於是先解除對它的鎖定，
    // 這樣至少能在下面寫檔的時候不讓 ReloadLogger() 卡住。
    data.conf_mutex.Unlock();

    string msg = rec.Encode(data.mode);
    data.file.Write(msg);

    data.file_mutex.Unlock();
}

你看這些解決方案都是有代價的！統一互斥子的鎖定順序雖然避免了死鎖問題，但也讓 WriteLogger() 函式每次呼叫進來都要鎖定 conf_mutex 互斥子，而原先是只有在少數需要的時候才會去鎖定 conf_mutex 互斥子。因此這項修改的代價就是讓每次 WriteLogger() 的呼叫多出了可能的額外等待。

那麼如果換個鎖定順序呢？這次我們改成規定鎖定順序是先 file_mutex 再 conf_mutex。在此方案下，原來的 WriteLogger() 就不需要修改，而是 ReloadLogger() 需要修改成像下面這樣：

void ReloadLogger(Logger &data, string name, int mode)
{
    // 本來後面不一定會需要鎖定 file_mutex 互斥子，
    // 但是後面有需要再鎖定的話就沒法符合鎖定順序的要求，
    // 因此只要後面可能有需要，就要在這裡先行鎖定。
    data.file_mutex.Lock();

    // 作為一個設計用來變更設定配置的函式，
    // 本來就需要鎖定 conf_mutex 互斥子。
    data.conf_mutex.Lock();

    data.mode = mode;

    if( data.name != name )
    {
        data.name = name;

        if(data.file.IsOpened())
            data.file.Close();
    }

    data.conf_mutex.Unlock();
    data.file_mutex.Unlock();
}

採用這個鎖定順序下，WriteLogger() 的效能不受影響了，但是換成每次的 ReloadLogger() 呼叫無論實際需要不需要都得去鎖定 file_mutex，使得 ReloadLogger() 本身因為可能需要的額外等待而導致執行耗時變長。

於是接下來就會進入衡量利弊的環節。規範統一的互斥子鎖定順序可以避免死鎖問題，但是要統一使用何種鎖定順序則可能會影響程式最終在不同情況下的表現，而其中的得失取捨就是設計者們需要針對各自的實際條件去考量計劃的問題。以本篇的 Logger 範例來看，我預期 WriteLogger() 無論是呼叫的數量還是頻率都會遠高於 ReloadLogger()，因此採用先 file_mutex 再 conf_mutex 的鎖定順序總體來看會比較有利，其核心就是以 ReloadLogger() 的性能犧牲去保全 WriteLogger() 的性能。

結論

本篇介紹了多緒設計裡所不樂見的死鎖問題與它的發生原因，並解釋了使用多個互斥子來分別保護不同組別的資源是為了可以減少不必要的鎖定機會以提升效能。為了避免死鎖問題，當需要同時鎖定多個互斥子時需要約定並遵守一致的鎖定順序，這在解決死鎖問題發生機會的同時也會導致某些情況下的程式效能犧牲，而這部份需要程式設計者針對各自的實際設計與使用情況去做考量斟酌。

執行緒同步 8：讀寫鎖

Fri, 27 Feb 2026 16:26:19 +0800

本篇再來介紹另一個互斥鎖的變體，是在特定應用場景下能夠改善鎖定效率的執行緒鎖：讀寫鎖(Readers-Writer Lock)。

情境

在介紹這種執行緒鎖之前，先來看一段範例程式，看看是什麼樣的情況與問題使得我們需要這麼樣一個解決方案？

本篇的範例假定的情況是有一個執行緒負責執行某種複雜的服務內容，而其它的一些軟體模組(當然也是不同的執行緒)便需要經常查詢這個服務的當前狀態，比如說服務資訊、版本、正在做的事情、完成進度……等等各種狀態內容，以便依據這些內容來決定自己接下來該幹什麼？於是範例內就有一條執行緒負責每隔一段時間更新一段模擬的訊息資訊內容，然後另外 6 條執行緒每隔一段時間要去讀取這個訊息內容，分析並決定接下來要做什麼。當然作為一個簡單的範例，把那個「分析並接下來幹什麼」的那部份省略了，只著重了讀取資訊的部份。

以下就是範例所定義的服務狀態資訊：

struct DummyInfo
{
    char description[128];
    unsigned version;
    int id;
    int level;
    bool activated;
};

然後是定時更新資訊的執行緒：

struct ServerData
{
    pthread_t thrd;
    bool go_term;

    pthread_mutex_t lock;
    struct DummyInfo stat_info;

    unsigned period;
    unsigned w_count;
    unsigned w_spend;
};

void* ServerThread(struct ServerData *data)
{
    for(; !data->go_term; SleepMs(data->period))
    {
        unsigned begin_time = GetMsTime();
        pthread_mutex_lock(&data->lock);

        // 更新記載某些狀態資訊的資料
        data->stat_info.version = 101;
        data->stat_info.id = 25;
        data->stat_info.level = ( data->stat_info.level + 1 ) % 5;
        data->stat_info.activated = !data->stat_info.activated;
        sprintf(
            data->stat_info.description,
            "A test server, level=%d",
            data->stat_info.level);

        // 為了模擬出更加容易被觀察的現象，
        // 這裡小休眠一下以放大在更新資訊時可能需要消耗的時間。
        SleepMs(100);

        pthread_mutex_unlock(&data->lock);
        unsigned end_time = GetMsTime();

        // 計算和儲存本次讀寫所消耗的時間
        data->w_count ++;
        data->w_spend += end_time - begin_time;
    }

    return NULL;
}

再然後是定時索取狀態資訊的執行緒：

struct ClientData
{
    pthread_t thrd;
    bool go_term;

    struct ServerData *server;
    struct DummyInfo stat_info;

    unsigned period;
    unsigned r_count;
    unsigned r_spend;
};

void* ClientThread(struct ClientData *data)
{
    for(; !data->go_term; SleepMs(data->period))
    {
        unsigned begin_time = GetMsTime();
        pthread_mutex_lock(&data->server->lock);

        // 從目標位置讀取狀態資料並存放到自己的記憶體位置，
        // 以待後續分析處理。
        // (當然在本範例中並不需要任何的後續處理)
        data->stat_info = data->server->stat_info;

        // 為了模擬出更加容易被觀察的現象，
        // 這裡小休眠一下以放大在讀取資訊時可能需要消耗的時間。
        SleepMs(50);

        pthread_mutex_unlock(&data->server->lock);
        unsigned end_time = GetMsTime();

        // 計算和儲存本次讀寫所消耗的時間
        data->r_count ++;
        data->r_spend += end_time - begin_time;
    }

    return NULL;
}

完整的範例程式碼可以從這裡下載，而以下是在我的電腦上執行的結果輸出：

Write statistics: count=31, total-spend=5868, ave-spend=189
Read statistics: count=184, total-spend=17756, ave-spend=96

從輸出的統計結果可看到，平均每次更新狀態資訊時消耗的時間為 189 毫秒，而平均每次讀取資訊則消耗 96 毫秒，二者皆接近原先預期的兩倍。確實互斥子的使用本身會帶來些許開銷，但是如本篇測試中多達數十上百毫秒的消耗已遠遠超過執行緒排程及上下文切換所致的結果，其大量的消耗其實是來自於等待其它執行緒歸還通行牌的過程。那麼有沒有什麼方案能夠改善這樣的不利因素呢？有的，就是本篇介紹的讀寫鎖。

Note	為了模擬一些真實的情況，又不想讓範例程式變得和真實程式一樣龐大複雜，於是我在程式碼中的資料讀寫都額外的加上了一小段休眠，以模擬對資料的讀寫更新可能產生的些許讀寫負擔；並且為了讓其效果能夠被輕易的觀察和比較，又稍微誇張化的放大了讀寫延時。其中在更新狀態資料時的延時為 100 毫秒，而讀取狀態資料時的延時為 50 毫秒。

讀寫鎖

在前面的測試程式執行的結果，我們發現無論是對於資料的讀或寫的整個過程都消耗了非常多的時間。即便從前我們知道像互斥子這種鎖本身附帶一些可觀的開銷，然而這點開銷在本次的測試結果裡面卻相形之下少到幾乎可以忽略不計！其主要多餘出來的等待時間還是來自於等待其它執行緒解鎖的過程。那麼究竟是什麼問題導致的呢？原來是參與讀寫的執行緒實在是多了！

如果說每個執行緒鎖定臨界區段都是在執行那些真的會衝突的東西，都是那些非得要排它的東西的話，那麼這問題就只能夠這個樣子了，執行緒們總歸還是要老老實實的排隊等待，而這時設計優化的目標可能就會變成是否減少不必要的讀寫機會或頻率。但是我們這次面對的情況卻有些特殊，雖然參與競爭的執行緒數量多了點，但是絕大部分執行的都是資料讀取的動作；然而，讀取的動作會導致競爭嗎？讀取的行為真的有必要上鎖排隊嗎？回顧執行緒為什麼發生資料衝突競爭等問題的內容，會發現問題根源來自於資料修改。根本原因是因為資料的修改變更，才造成資料版本不一致(快取)的問題，以及工作流程中途被插隊導致的狀態錯亂問題。但是純讀取的操作並不修改資料啊！誰管你想怎麼樣快取、怎麼樣調整執行順序、又怎麼樣被插隊呢？是的，確實是如此。那麼如果我們允許讓純粹資料讀取的行為可以同時進行而不需要排隊等待的話，是不是就能減少許多不必要的時間等待浪費了呢？是的，這就是使用讀寫鎖的目的。

不過讀取與讀取之間雖然不會產生干擾衝突，但是讀取與寫入之間卻會！如果讀取和寫入能夠不被限制的同時進行的話，那麼就會讓我們有機會讀取到被更新到了一半的資料。於是讀寫鎖的設計仍然需要將要寫入資料的執行緒與其它要讀取資料的執行緒互斥，當然同樣也需要和其它也想要寫入資料的執行緒互斥；至於如果都是讀取資料的執行緒，那就讓它們都一起進入臨界區段同時讀取吧！

面對所描述的這種應用情景，讀寫鎖應運而生。讀寫鎖(Readers-Writer Lock)常也被簡寫為 RW Lock，它基本的使用方式和邏輯與互斥子是一樣的，只不過在上鎖的時候需要區分為以寫入者身份來上鎖，或者以讀取者身份來上鎖。接著就讓我們來將上面範例程式的互斥子更換為讀寫鎖，首先是服務執行緒定時更新狀態資訊的執行緒：

for(; !data->go_term; SleepMs(data->period))
{
    unsigned begin_time = GetMsTime();
    pthread_rwlock_wrlock(&data->lock); // 以寫入者的身份要求上鎖

    data->stat_info.version = 101;
    data->stat_info.id = 25;
    data->stat_info.level = ( data->stat_info.level + 1 ) % 5;
    data->stat_info.activated = !data->stat_info.activated;
    sprintf(
        data->stat_info.description,
        "A test server, level=%d",
        data->stat_info.level);

    SleepMs(100);

    pthread_rwlock_unlock(&data->lock); // 解鎖
    unsigned end_time = GetMsTime();

    data->w_count ++;
    data->w_spend += end_time - begin_time;
}

然後是讀取狀態資訊的執行緒：

for(; !data->go_term; SleepMs(data->period))
{
    unsigned begin_time = GetMsTime();

    pthread_rwlock_rdlock(&data->server->lock); // 以讀取者的身份要求上鎖

    data->stat_info = data->server->stat_info;

    SleepMs(50);

    pthread_rwlock_unlock(&data->server->lock); // 解鎖
    unsigned end_time = GetMsTime();

    data->r_count ++;
    data->r_spend += end_time - begin_time;
}

完整的程式碼可以從這裡下載，而程式的執行結果如下：

Write statistics: count=35, total-spend=4573, ave-spend=130
Read statistics: count=197, total-spend=12768, ave-spend=64

改用讀寫鎖來取代互斥子之後，明顯的能看出統計出來的結果大大優於使用互斥子的版本。就以本篇範例來看，使用讀寫鎖的版本相比於使用互斥子的版本縮短了大約 30% 左右的等待時間。

適用場合

讀寫鎖看起來相當美好，但從這裡我又要開始來拆臺了。讀寫鎖之所以能夠帶來相當的性能提升，是建立在適當合適的使用條件之下的，尤其本文所設計的範例更是針對貼合此情境而設計；然而若將讀寫鎖應用在並不匹配的場合，則可能使它實際的效能與互斥子相比並不優越，甚至有可能更加劣化！

讀寫鎖其實是一種更加複雜的鎖，甚至於某些讀寫鎖的底下其實就是靠著兩個互斥子來組合實現的 ^[1] ，也就是說讀寫鎖本身的使用操作之開銷其實是比普通的互斥子還要更高一些的。而使用讀寫鎖之所以相比使用互斥子可以節省時間，就如同前面所解釋的一樣，是因為它允許許多只讀取資料的執行緒可以重複上鎖、同時操作，是因為讀取與讀取之間不需要互相排隊等待。因此首先讀寫鎖適合的使用場景就是 很多緒共同存取資料，並且其中大多是只讀取，只有少部份需要寫入的場合。 (至於如果有人問大量讀取搭配沒有寫入？這種情況其實也沒必要上鎖了！) 而如果不是此種情況，例如在大量的寫入修改並搭配少量只讀或甚至沒有只讀而都是修改，例如本系列前篇的訊息工廠和消費者範例那樣，那麼讀寫鎖的優勢將難以發揮，而讀寫鎖也將形同於比普通互斥子更加複雜些的互斥子。

除了滿足上述多緒共同讀取的條件之外，還需要第二個條件，就是對共同資料的讀寫需達到某種程度以上的開銷。這是什麼意思呢？舉個誇張點但其實相當常見的例子，比方說我們需要讀取的狀態其實只是一個整數值，而不是像本篇範例那樣比較複雜的內容。在臨界區段實際上非常小巧緊湊的情況下，上鎖和解鎖的時間非常非常短暫，這時讀寫鎖允許多緒共同進入臨界區段的優勢並無法發揮出來。因為讀寫鎖本身其實可算是普通互斥子的一種擴展方案，也就是說一般互斥子該有的特性它都有，就導致其上鎖與解鎖的開銷仍在並與普通互斥子不相上下，而在臨界區段相當短小的情況下其實這才是主要的延時來源！也就是說對於某些很多讀取而少許寫入的場合，看起來好像適合使用讀寫鎖，然而因為需要被保護的東西其實相當少量並且實際上飛快就能完成讀寫，那麼這時候可能使用普通的互斥子其實也沒有什麼差別，甚至於或許使用自旋鎖反而會更加高效！這就是為什麼本篇範例對於共同資料的讀寫那一段加入了人為的延時的原因，因為這樣做才能夠在單純的範例程式碼裡面將讀寫鎖的優勢給凸顯出來。

除此之外還有另外一種可能，說不定其實並不一定需要上鎖！ 競爭的問題其實是跟著多緒寫入而導致的，然而在許多實際的應用中往往可能其實只有一條執行緒在更新某些資料，然後其它執行緒只讀取。那麼在此情況下使用鎖來做保護仍是必須的嗎？那就不一定了！對於單緒寫入、多緒讀取的情況如果仍需要做保護，那就只有兩個原因：或者是怕讀到了才被更新到一半的資料，比如本篇的範例如果去掉保護的話就有可能發生這種現象；或者是怕取得的資料不能即時反應當下的最新狀態，這主要是因為負責寫入的動作可能還來不及將快取資料刷回去所導致，而這在某些對於資料同步一致性性高度敏感的用途上可能會造成程式行為不正確對應的問題。

然而如果我們的程式並不存在上述的兩個問題呢？比方可能相當常見的只使用一個整數來表示某種狀態，而整數對於可能絕大部份的執行平臺上都是一步就能更新完成的；除非像是在 32 位元 CPU 上更新一個 64 位元整數的動作才會被拆成兩個步驟分別更新。 (也許有讀者可能會問說明明在前篇敘述這些簡單動作其實需要好多 CPU 指令的，怎麼現在變成一步完成了呢？ 那是因為現在討論的是單緒寫入的情境，管它為了這件事需要幾個指令呢， 反正最後將資料更新回去只有一個指令，不存在讓其它人讀到「一半新、一半舊」的問題！) 或者即便是像本篇的範例這樣需要更新一組資料結構，那不上鎖的話的確可能會發生取到被更新到一半的資訊的問題，但假若我一個讀取者其實並不是需要分析整個資料，而其實只需要裡面的其中一個整數值呢？

所以在很多乍看可以應用讀寫鎖的地方，比如最常見的讀取一個整數值的情況，其實壓根並不需要任何形式的鎖定；就算我們的程式需要即時最新的數值資訊，而不希望因為快取什麼的因素導致取得的資訊有些落後，而在我們的程式上會造成可能某些嚴重的後果，那也只需要使用原子變數就能夠解決了，並不需要用上讀寫鎖。從作者我的實務經驗來看，其實真正需要使用讀寫鎖的場合並不多見。當然這並不是說讀寫鎖毫無用武之地，這最終還是要看應用場合的，像我從前在做檔案系統驅動程式的時候用的就挺多！這裡只是在告訴你讀寫鎖還是有它自己的適與不適條件存在，並且在平均大多的情況下其實適合應用的地方可能並不多，至少可能不比我們剛認識學習讀寫鎖的時候所想像的那麼好用。總之只有在我們足夠了解它的特性之後，才能更加準確的判斷在真正適合的地方，讓它發揮應該有的效用。

總結

本篇介紹了讀寫鎖，加上前幾篇介紹的幾個鎖，正好湊齊了一組執行緒鎖。這幾個鎖看來看去其實會發現，它們都是互斥鎖的不同變種！無論是互斥鎖、自旋鎖、還是讀寫鎖，其實都可以概括歸類於互斥鎖大類別之下。三種鎖的使用邏輯基本都是一樣的，上鎖、解鎖、保護中間的臨界區段，只不過不同的所針對不同的應用場景做了優化。也就是說自旋鎖和讀寫鎖其實都是互斥鎖針對特定場景下的效能優化變種，如果不在乎效能最佳化的話，甚至可以就只學了個互斥鎖就到處使用，也都不影響程式的運作邏輯。甚至於更誇張的話其實連原子變數也不用學，只要懂一個互斥鎖那也能到處走天下闖江湖，也許做出來的東西不見得比別人高效，但並不影響能把功能給做出來。

然而如果追求好還要更好，那麼學習這些「多餘的」東西就是必不可少。並且除了知道才什麼情況下使用什麼東西可以更進一步增進效能之外，我認為更重要的是要知道在什麼情況下使用什麼東西沒有幫助，甚至於弊大於利導致性能倒退與其它問題。而這些只有在足夠了解各種工具的底層邏輯的情況下才能夠掌握的游刃有餘，真正成為幫助我們設計程式的上手工具。

1. Readers–writer lock

執行緒同步 7：自旋鎖

Sat, 21 Feb 2026 23:07:13 +0800

在前篇介紹了互斥鎖之後，本篇要來介紹一個與其非常雷同但又有點不同的鎖：自旋鎖(Spinlock)。

在前篇的範例情境中，我們的程式碼遭遇了一個比較複雜的情況，於是引入了使用彈性強大的互斥子來解決執行緒之間的衝突保護問題。然而互斥子方便歸方便，但是使用的代價卻有點兒巨大，主要是因為當執行緒之間共同競爭的時候會導致進入休眠，而執行緒的休眠與喚醒會產生相當可觀的時間延遲，如果正好碰上頻繁且短暫的加鎖與解鎖的使用情況，那就將會帶遠遠超出真正需要的休眠延遲，導致性能衰減過多。而對與此種情況的最佳解決方案，可能就是本篇將要介紹的「自旋鎖」(Spinlock)。

如果上面的說明顯得過於抽象，那就讓我們重新回顧前篇的那個數值累加的範例，那就是一個典型的適合自旋鎖的使用場景。

for(int i = 0; i < n; ++i)
{
    mtx_lock(&data->mutex);
    data->value += x;
    mtx_unlock(&data->mutex);
}

在上面的數值累加核心內容裡，我們使用互斥子來保護可能會導致多緒衝突的累加程式碼敘述，然而這卻帶來了一個可能不必要的過多等待的問題。比方說如果此時有兩個執行緒正好一起執行了上鎖互斥子的呼叫，當然我們知道只會有其中一條執行緒得以立刻通行而另一條執行緒得等待。只不過看看臨界區段的內容，就是簡單的加法、賦值，頂多加上結構與指標的索引工作，換算成 CPU 指令可能也就只有沒幾條命令，實際上可能只需要幾個 CPU 指令週期的時間就做完了，然後執行緒就呼叫解鎖互斥子歸還通行牌，拂袖揚長而去。

就這樣，前一個執行緒飛快的做完了臨界區段的程式碼，於是緊接著馬上輪到第二條執行緒進入臨界區段接著執行是不是？然而實際上並不是這麼簡單，因為那第二條執行緒已經進入休眠等待的狀態了！即便從當時搶通行牌搶輸了的時間開始計算，到贏家率先做完工作解鎖互斥子可能只花了 1 耐秒的時間，即便只花了 1 耐秒互斥子就告知你可以醒過來繼續通行，然而從休眠狀態要醒過來的執行緒還得在慢慢等待作業系統排程排到它，等執行緒真正回復執行狀態並接著進入臨界區段的時候，可能好幾個毫秒已經過去了。區區幾個毫秒也許並不會讓人感受到什麼變慢的感覺，但是再加上這個範例剛剛好又是個非常頻繁進出臨界區段的應用場合，於是這個延遲就在不斷反覆當中被累積放大，最終成為巨大的性能落差。 (在我的電腦上，使用原子變數的累加程式總共消耗的執行時間為 5.592 秒， 而使用互斥子的版本則為 31.544 秒。)

那麼如果我們改寫一下關於加鎖和解鎖的部份，不使用原本的互斥子而改用我們自己實現的互斥子 mylock_t，以及相關操作函式 mylock_lock() 和 mylock_unlock() 來取代它：

for(int i = 0; i < n; ++i)
{
    mylock_lock(&data->mutex);
    data->value += x;
    mylock_unlock(&data->mutex);
}

其中我們自製版本的互斥子以及幾個關鍵的操作函式之實現內容如下：

#include <stdatomic.h>

typedef atomic_flag mylock_t;

void mylock_init(mylock_t *mutex)
{
    atomic_flag_clear(mutex);
}

void mylock_lock(mylock_t *mutex)
{
    while(atomic_flag_test_and_set(mutex))
    {
        // 沒事做，空耗著！
    }
}

void mylock_unlock(mylock_t *mutex)
{
    atomic_flag_clear(mutex);
}

就這樣實現了一個自製版本的互斥子。其中最關鍵的內容其實就在於那個 mylock_lock() 函式，其內容就是透過值交換的操作不斷反覆檢查一個原子變數的值是否為零，如果為零則表示我是第一個拿到通行牌的幸運者，不為零則表示通行牌已被取走並且尚未歸還；而解鎖，也就是歸還通行牌的操作就只是簡單的將變數重設為零。乍看之下那個類似無限迴圈的程式碼會讓 CPU 不斷循環反覆做白工，理論上會導致資源管理器上面的 CPU 使用率飆高，風扇狂轉，空耗 CPU 運算力；然而因為臨界區段的程式碼相當精簡小巧以至於飛快就做完了，因此實際上這個形似無限迴圈的等待其實可能只轉沒有幾圈就得到了通行牌。最後的結果就是實際上空耗等待的時間相當短暫，而又避免掉了執行緒進入休眠再喚醒的過程，從而使得它的響應速度非常快速即時。

因為這種鎖的重要實現核心在於那個看似空耗 CPU 性能的迴圈，其如同芭蕾舞者在那空轉旋轉的運作特性，於是這種鎖就被命名為「自旋鎖」(Spinlock)。不過除了在某些老舊或比較不尋常的開發環境下可能會需要我們自己實現這種鎖之外，現實中其實各大執行緒相關函式庫通常已經提供了這種自旋鎖可以讓我們直接使用(不過 C11 沒有)，因此本篇的範例並沒有使用上面那樣實現的自旋鎖，而是呼叫了 pthread 程式庫所提供的自旋鎖(pthread_spinlock_t)：

for(int i = 0; i < n; ++i)
{
    pthread_spin_lock(&data->lock);
    data->value += x;
    pthread_spin_unlock(&data->lock);
}

範例完整程式碼可從這裡下載，其在我電腦上的執行結果如下：

Finished, value=800000000/800000000, spend=20546

對比不同保護方案所得到的結果，採用原子變數的方案消耗時間為 5.592 秒，採用互斥子的方案為 31.544 秒，而採用自旋鎖的方案則為 20.546 秒。從測試結果可見自旋鎖雖然相比原子變數也是相當大的劣勢，然而與常用的互斥子相比卻是提升了相當可觀的效能。

Note

不過其實單單就這個範例來看，顯然最佳的解決方案是使用原子變數而非自旋鎖。也就是說，在能夠使用少數原子變數來解決的問題上，例如單個變數的簡單操作計算來說，使用原子變數通常會是最佳的作法；而當需要保護的衝突操作較多較複雜而難以使用單純的原子變數來覆蓋的時候，則使用互斥子；而當臨界區間程式碼相當簡單簡短且未涉及系統呼叫或等待，但是又足夠複雜到無法使用原子變數來覆蓋的情況下，則自旋鎖就可能是相當合適的採行方案。依此原則，其實同樣在前篇的那個使用了鏈結串列的生產者與消費者程式，才是在實務上比本篇範例更加適合應用自旋鎖的場合；然而因為效能計算與比較上的方便，本篇還是採用了數值累加的程式碼來做自旋鎖的性能測試。

適合與不適合

自旋鎖看起來這麼美好，然而那是因為本篇所示例的應用場景恰好適合自旋鎖的緣故。而自旋鎖其實在使用上相當考驗「因地制宜」的程式設計，一旦使用在不合適的地方則可能導致性能不升反減，順便夾帶 CPU 功耗與溫度飆升的副作用！因此了解自旋鎖的內部邏輯，並且妥善設計在適合的地方使用自旋鎖，就成為相當重要的程式設計功課。

自旋鎖最核心的運作邏輯就是那個空耗 CPU 效能的迴圈，在合適的使用場景之下會因為其即時的響應速度而得到相當優秀的性能提升，並且其空耗的劣勢也會因為簡潔精煉的臨界區段導致實際上空耗的時間同樣非常少，劣勢並不顯著，而這也就是最適合使用自旋鎖來取代互斥子的最佳使用場景。

然而一旦臨界區段內的程式複雜冗長起來，甚至於可能呼叫了系統資源配置或進入休眠等待等情況，則自旋鎖的使用就變成優勢不顯而劣勢凸出了！如果臨界區段需要花費可觀的運算時間，甚至於可能會進入休眠等待狀態，那麼人家簡單休眠個幾毫秒或幾十、幾百毫秒也許並不會消耗什麼系統資源；然而你的自旋鎖也要在那邊空轉消耗上百毫秒的話，那影響可就太大了！也許你會說頂多了不起就是 CPU 使用率飆升，風扇狂轉罷了，電腦扛得住的，至少自旋鎖的反應快啊！然現實卻不然，先別說當臨界區段的時間跨度來到上百毫秒甚至更多的時候那曲曲幾個毫秒的時差算得上什麼事了，就光因為自旋鎖空轉佔掉了 CPU 的計算力，可能就導致排擠了其它執行緒的執行機會，最終反而變成溫度飆高、風扇狂轉，但程式整體卻可能反應更加遲鈍且效率更加低下的結果！

除此之外還有一個同樣不適合使用自旋鎖的環境，那就是單核 CPU 的運算環境下。話說當代新買的電腦大概 CPU 沒有個 4 核心都會被人笑掉大牙了，根本也買不到那種單核 CPU，然而其實出了 PC 範圍的話，在某些較為低端的設備上面其實還挺常見單核心 CPU 的。回顧自旋鎖的原理，自旋鎖之所以能夠發揮反應迅速的能力，其實根本基礎在於多核心的平行運算。就是因為存在真實同步進行的平行執行緒，才產生了可能自旋鎖才自旋幾圈就等到其它執行緒釋放鎖的機會。然而當程式運作在單核心 CPU 環境下時，若非等到排程器切換使另一個執行緒得到執行的機會，這個自旋鎖無論怎樣自旋空耗 CPU，都不可能等到鎖被釋放的。於是自旋鎖只能夠一直空轉一直空轉，直到自己的時間片耗完並被排程器給切換出去為止。因此若真的需要將程式放在單核心 CPU 環境下執行的話，還是老老實實使用互斥鎖吧！

總結

本篇介紹了一種用途極其類似於互斥子的自旋鎖，在合適的場合下取代互斥子的使用時，也就是臨界區段簡潔且執行快速時，可以得到相當可觀的性能提升效果；然而當使用在並不適合的場合下，也就是臨界區段耗時較多或甚至需要進行系統資源配置或等待時，那麼自旋鎖的使用將會導致 CPU 效能的無端消耗，並可能使程式效能更加劣化。此外在非多核心或多 CPU 的執行平臺，也就是單 CPU 單核心的執行環境下，自旋鎖的使用沒有意義，應該改回使用互斥子。

執行緒同步 6：互斥子

Thu, 19 Feb 2026 15:01:08 +0800

上集介紹了應用在執行緒同步用途當中最簡單快速便利的原子變數(Atomic Variable)。然而原子變數的使用彈性相當有限，在實際的應用用途中但凡我們程式的資料運算邏輯稍微複雜一點，原子變數很容易就不敷使用了。那麼本篇我就來介紹一種在多緒同步用途中使用最廣泛、出鏡率最高的一種同步工具：互斥子(Mutex)。

使用情境

在解釋互斥子之前，先讓我們看一段程式碼，以先了解適合引入互斥子的使用情境。

這次的測試範例是一個典型的「生產者/消費者」模式，範例程式建立了一個稱為「工廠」的執行緒，在一分鐘的時間內每隔 50 毫秒就會產生一筆消息出來，然後另外 4 個訂閱了訊息的「消費者」執行緒就會不斷的嘗試去拿取工廠發送出來的資料，拿到之後就去處理那份資料。當然作為一個測試用的範例，所謂的處理資料也就是將訊息內所記錄的字串給輸出出來而已。

那麼首先，下面這個就是本次範例所圍繞的中心，也就是上面描述的那個「消息」的資料格式：

struct Message
{
    // 用來將多個訊息組成串列而需要的資料結構
    struct Message *prev;
    struct Message *next;

    // 記錄訊息內容以及產生訊息的時間
    unsigned ctime;
    char str[128];
};

這個消息採用雙向鏈結串列的設計，這樣萬一消費者來不及取走資料的話，工廠不斷生產出來的資料就會組成一個串列一直暫存在那裡等待被取走，而不會被覆蓋或流失掉。不過關於鏈結串列的細節部份並不是本篇的重點，本篇只是借用這套演算法而已，所以本篇不會過度注重在相關的內容上。如果您不知道什麼是鏈結串列且又有興趣想要了解學習，那麼可以參考其它的說明資源 ^[1]。

有了消息本身的資料結構以後，下面就是用來產生消息的執行緒：

struct Factory
{
    // 記錄要產生的消息數量和時間間隔
    unsigned period;
    unsigned total_num;

    // 用來堆放消息的鏈表頭尾指標
    struct Message *first;
    struct Message *last;

    // 執行緒本身有關的資源
    thrd_t thrd;
};

int FactoryThread(struct Factory *data)
{
    for(unsigned i = 0; i < data->total_num; ++i)
    {
        struct Message *msg = malloc(sizeof(*msg));
        msg->ctime = GetMsTime();
        snprintf(msg->str, sizeof(msg->str), "message-%u", i);
        printf("Factory: Generate \"%s\"\n", msg->str);

        msg->prev = data->last;
        msg->next = NULL;

        if(!data->first)
            data->first = msg;
        data->last = msg;

        SleepMs(data->period);
    }

    return 0;
}

如上所見，工廠執行緒內容就是一個簡單的迴圈，定時不斷產生訊息並將訊息推送到鏈表緩存，等待消費者稍後取走。

完了之後再看下面的消費者執行緒都在做什麼？反正執行緒的函式外殼都是一樣的，這裡就不再重複展示了，下面只展示消費者執行緒函式裡面的重點迴圈部份：

while(!data->go_term)
{
    struct Factory *src = data->msg_src;

    struct Message *msg = src->first;
    if(msg)
    {
        src->first = msg->next;
        if(!src->first)
            src->last = NULL;

        if(msg->next)
            msg->next->prev = NULL;

        unsigned delay = GetMsTime() - msg->ctime;
        printf("Consumer[%u]: Process \"%s\", delay=%u\n",
            data->idx, msg->str, delay);
        free(msg);
    }
}

如上所見，消費者執行緒就是不斷探測工廠有沒有存在可用的消息？如果有的話就把消息從鏈表裡取走，然後處理消息，也就是顯示消息的內容。其中注意在執行緒的迴圈裡就使用到了前篇介紹過的用來正常結束執行緒的方法。每次迴圈都會檢查一個旗標值，只要旗標值沒被設定的話就繼續不斷反覆執行迴圈內的工作，執行緒就會永遠處在工作中不會返回；而外面的控制者，在範例中就是我們的主函式，則可以透過設定這個旗標值來讓執行緒知道該結束工作了。

上面這個範例的完整程式碼可以從這裡下載。然而光看上面的示例說明，眼尖的讀者可能已經發現不對勁的地方了！上面兩個執行緒(其實是 5 個執行緒，因為消費者執行緒一共建立了 4 條)彼此共同存取了好多變數，而這些變數的存取完全沒有任何保護，肯定會發生執行緒資料競爭的問題。果不其然，這個範例從一執行開始就發生了許多奇異現象，執行沒有幾步更是直接當掉了！下面就是這個範例在我電腦上執行的結果：

Factory: Generate "message-0"
Consumer[0]: Process "message-0", delay=0
Factory: Generate "message-1"
Consumer[0]: Process "message-1", delay=0
Consumer[2]: Process "message-1", delay=0
Consumer[3]: Process "message-1", delay=0
Consumer[1]: Process "message-1", delay=0
Factory: Generate "message-2"
Consumer[2]: Process "message-2", delay=0
Consumer[3]: Process "message-2", delay=0
Consumer[1]: Process "message-2", delay=0
Consumer[0]: Process "message-2", delay=0
Factory: Generate "message-3"
Consumer[3]: Process "message-3", delay=0
Consumer[2]: Process "message-3", delay=0
Consumer[1]: Process "message-3", delay=0
Consumer[0]: Process "message-3", delay=0
Factory: Generate "message-4"
Consumer[2]: Process "message-4", delay=0
Consumer[3]: Process "message-4", delay=0
Consumer[1]: Process "message-4", delay=0
Consumer[0]: Process "message-4", delay=0
Factory: Generate "message-5"
Consumer[2]: Process "message-5", delay=0
Consumer[1]: Process "message-5", delay=0
Consumer[3]: Process "message-5", delay=0
Consumer[0]: Process "message-5", delay=0
Factory: Generate "message-6"
Consumer[2]: Process "message-6", delay=0
Consumer[1]: Process "message-6", delay=0
Consumer[3]: Process "message-6", delay=0
Consumer[0]: Process "message-6", delay=0
Factory: Generate "message-7"
Consumer[2]: Process "message-7", delay=0
Consumer[1]: Process "message-7", delay=0
Consumer[3]: Process "message-7", delay=0
Consumer[0]: Process "message-7", delay=0
Factory: Generate "message-8"
Consumer[2]: Process "message-8", delay=0
Consumer[3]: Process "message-8", delay=0
double free or corruption (out)
Consumer[0]: Process "message-8", delay=0
Aborted (core dumped)

既然會發生執行緒競爭的問題，那麼就要來想辦法避免競爭。那將上範例中的那些共同存取的變數改成使用原子變數可不可以呢？這個方法在本篇的範例裡顯然是解決不了問題的！首先這並不是因為本次的問題出在指標上而不能保護，因為 C11 定義中也存在 atomic_uintptr 這樣的原子變數型態，而之所以無法解決衝突的問題是因為這次牽涉其中的變數太多了！原子變數只能夠保證對那個變數本身的存取與修改是無法被中途插隊的原子操作，可是本次範例中暴露在多緒共同編修的變數卻有好多個，就算每一個都改使用原子變數，也沒有辦法阻止在一個接一個執行原子變數的操作中間被別的執行緒插隊的問題。

這就是光使用原子變數也對於像本篇範例這樣的使用情境只能雙手一攤的原因所在了。那麼為了解決在這樣的使用場景中所面臨的執行緒衝突問題，我們就需要更加強大的保護機制(或稱同步機制)。

互斥子(Mutex)

先不多做解釋，先來看看給上面的範例加上互斥子的樣子。首先是消費者執行緒的部份：

while(!data->go_term)
{
    struct Factory *src = data->msg_src;

    mtx_lock(&src->mutex);      // 加了這一行

    struct Message *msg = src->first;
    if(msg)
    {
        src->first = msg->next;
        if(!src->first)
            src->last = NULL;

        if(msg->next)
            msg->next->prev = NULL;
    }

    mtx_unlock(&src->mutex);    // 加了這一行

    if(msg)
    {
        unsigned delay = GetMsTime() - msg->ctime;
        printf("Consumer[%u]: Process \"%s\", delay=%u\n",
            data->idx, msg->str, delay);
        free(msg);
    }
}

然後是工廠執行緒的部份：

for(unsigned i = 0; i < data->total_num; ++i)
{
    struct Message *msg = malloc(sizeof(*msg));
    msg->ctime = GetMsTime();
    snprintf(msg->str, sizeof(msg->str), "message-%u", i);
    printf("Factory: Generate \"%s\"\n", msg->str);

    mtx_lock(&data->mutex);     // 加了這一行

    msg->prev = data->last;
    msg->next = NULL;

    if(!data->first)
        data->first = msg;
    data->last = msg;

    mtx_unlock(&data->mutex);   // 加了這一行

    SleepMs(data->period);
}

而當然，幾個執行緒必需要操作的是同一個互斥子才能夠發揮效果，於是這邊選擇將互斥子的實體放在工廠執行緒的資料裡面，就在鏈結串列相關變數的旁邊：

struct Factory
{
    unsigned period;
    unsigned total_num;

    mtx_t mutex;            // 加了這一行
    struct Message *first;
    struct Message *last;

    thrd_t thrd;
};

上面的程式修改內容其實就是簡單的在所有進行那些會倒置衝突的「關鍵程式碼」前後分別加上 mtx_lock() 和 mtx_unlock() 呼叫。修改完成後，這個範例程式的執行就沒有問題了，從頭到尾一氣呵成也無錯誤歧異。範例的完整程式碼可以從這裡下載，整個範例程式的輸出有兩千多行，下面只節錄其中一小片段作為代表：

Factory: Generate "message-71"
Consumer[0]: Process "message-71", delay=0
Factory: Generate "message-72"
Consumer[1]: Process "message-72", delay=0
Factory: Generate "message-73"
Consumer[3]: Process "message-73", delay=0
Factory: Generate "message-74"
Consumer[0]: Process "message-74", delay=0
Factory: Generate "message-75"
Consumer[2]: Process "message-75", delay=0
Factory: Generate "message-76"
Consumer[2]: Process "message-76", delay=0
Factory: Generate "message-77"
Consumer[0]: Process "message-77", delay=0
Factory: Generate "message-78"
Consumer[2]: Process "message-78", delay=0
Factory: Generate "message-79"
Consumer[3]: Process "message-79", delay=0
Factory: Generate "message-80"
Consumer[0]: Process "message-80", delay=0

從上面結果大致可以窺探，訊息的產生與消化、鏈結串列的各種操作都沒有意外，沒有訊息被多拿也沒有被少拿，指標變數的操作看似也沒有任何異常或錯亂， 4 個等待索取訊息的執行緒也大致都能平均拿到訊息而無明顯的不平衡。一切問題都解決了，就只是在關鍵操作的前後加上 mtx_lock() 和 mtx_unlock() 呼叫而已。

互斥子的使用

細說互斥子的使用，其使用與呼叫的基本結構如下：

// 這裡執行那些沒有競爭問題的程式碼
...
...

mtx_t *mutex = ...; // 不知從哪裡拿來的互斥子

mtx_lock(mutex);    // 向互斥子要求一個鎖，如果沒有鎖的話那就等待到有為止

// 這裡執行那些原本會產生衝突競爭的程式碼
...
...

mtx_unlock(mutex);  // 將鎖歸還給互斥子

// 繼續執行其它沒有競爭問題的程式碼
...
...

Note	由於不同的執行緒函式庫都存在互斥子且操作方式基本相同，因此下面將以更加概念通用且簡潔的名稱 `lock()` 和 `unlock()` 來表示互斥子的上鎖與解鎖呼叫，而不寫成 C11 標準裡的 `mtx_lock()` 和 `mtx_unlock()`。

互斥子就像是一個守門員，而 lock() 的呼叫其實就是向守門員索取一張通行牌，也就是鎖(lock)。互斥子給你一張通行牌，你就可以通行，這時 lock() 的呼叫就會正常返回，而你也就能繼續執行下面的程式碼。不過互斥子只有一張通行牌，如果同時有很多人都呼叫了 lock() 的話，那麼互斥子只能選擇其中一個幸運兒(通常就是最早呼叫的那個人)並把通行牌給他，而其它人就只能夠等待放行，具體就是除了那個幸運者之外的其他人都會被卡在 lock() 呼叫裡面不會返回。

於是如果所有需要操作那些原本能導致衝突的程式碼的執行緒都自律的在執行操作前先呼叫 lock() 的話，那麼大部份執行緒都得等待，只有也只會有一個執行緒能夠得到繼續往下執行的機會；既然只有一個執行緒在執行，自然就不會有衝突的問題，它可以從容的把所有操作處理完而無需擔心被別的執行緒從中插隊而導致錯亂。

等那個幸運抽中通行牌的執行緒執行完那些關鍵的操作之後，就可以呼叫 unlock() 作結，這個呼叫的意義就是將手上持有的通行牌歸還給互斥子。於是拿回了通行牌的互斥子就會再從剛才呼叫了 lock() 而進入等待的那些人之中挑選一個幸運兒，然後將通行牌發給他，於是他的 lock() 呼叫就會返回，並能像前一個執行緒那樣繼續執行下面的關鍵程式碼，並且只會有他這一個執行緒能夠執行那段程式碼，而其它執行緒依然繼續等待。

如此類推反覆，互斥子透過守門的方式讓所有執行緒排隊等待放行，一次只準一個放行通過，如此就解決了多緒共同競爭的問題。並且因為互斥子的保護範圍是從 lock() 到 unlock() 之間的所有內容，因此在那中間可以寫上任何複雜的操作都無所謂，操作空間和彈性非常大，完全不像原子變數那樣在用途上相當受限。這就是為什麼互斥子是在所有解決多緒問題當中最受廣泛使用的手段了，事實上在前篇曾描述過的那些 CPU 指令並不支援的原子變數，或甚至像 C++ 可以把任何自訂型態都變成原子變數的那些「假原子變數」，其內部都是使用這樣的互斥子來實現的。而那一段介於 lock() 呼叫到 unlock() 呼叫之間受保護的程式碼區域就有一個特別的名詞用來稱呼，那段受到互斥子保呼的程式碼區域就叫作「臨界區段」(Critical Section)。

互斥子的代價

既然互斥子這麼好用，使用彈性大，臨界區段能包容一切程式碼，那麼是不是所有的問題都用互斥子來解決就好了 (事實上確實大部份的多緒衝突問題都用互斥子來處理)，什麼原子變數什麼的其它方法手段毫無價值也無學習的必要了呢？當然也不是這樣，因為互斥子的使用本身也是附帶相當大的代價的！從前面的說明內容來看，互斥子能夠解決多緒衝突的核心方法就是讓執行緒排隊，一次只放行一個執行緒通過，其本質就是把多緒條件退化為單緒條件從而解決問題。那麼這有什麼問題呢？問題就在於大家得「等」！說的誇張一點，我們甚至可以把執行緒函式內的所有內容全都包在臨界區段內，但結果就會變成所有的執行緒都得排隊等著一個一個獲得執行的機會，活生生把多緒又回歸到單緒去了。

因此為了儘量減少執行緒之間大量的互相等待時間，我們在使用上就應該要儘量縮減臨界區段的內容，基本就是把所有其實不會衝突、不需要受到保護的內容移出到臨界區段外面去執行，讓那些程式碼可以在不同的執行緒中去平行進行，只保留最少量的那些真正可能會產生衝突而必須被保護的程式碼在臨界區段內，使執行緒需要排隊等待的範圍縮減到愈小愈好。在本篇前面的互斥子範例中就已經展現出這樣的設計原則，只將對鏈結串列的操作內容包裹在 lock() 和 unlock() 中間的臨界區段內，至於配置訊息記憶體空間以及填寫其內容的部份、以及處理和輸出訊息內容的部份，則放在臨界區段之外，不讓那些實際上不需要受到保護的程式碼去拖慢大家等待的時間。

然而即便已經試圖最大程度的壓縮臨界區段，互斥子的使用依然會帶來相當的性能開銷。其原因在於前面所說的「等待」通行牌的過程其實就是讓執行緒進入睡眠狀態，而睡眠的喚醒並不是即時的，具體得看作業系統的排程安排(可參閱前篇說明)。總之就是當一個執行緒歸還通行牌後，互斥子將通行牌派發給下一個執行緒，到下一個執行緒從休眠狀態回復過來真正開始執行之間存在一定程度的時間延遲。而具體到底能差到多少呢？讓我們把前篇那個計算累加的範例改用互斥子來做：

for(int i = 0; i < n; ++i)
{
    mtx_lock(&data->mutex);
    data->value += x;
    mtx_unlock(&data->mutex);
}

跑出來的結果如下：

Finished, value=800000000/800000000, spend=31544

可看到這個測試在我的電腦上一共花費了 30 多秒完成，對比使用原子變數的方案花費了大約 5 秒多，使用互斥子的方案大約使用了 6 倍左右的時間！ (當然連原子變數都不用而只用普通無保護變數的程式版本只花了 1 秒多的時間， 但是因為計算結果完全不正確，所以僅作為參考而已。) 總之結算下來，使用原子變數作為多緒之間的確保手段已經付出了 5 倍的效能劣化代價，而使用互斥子則對比原子變數又是 6 倍的效能劣化代價，足見互斥子(以及其它所有後續介紹的高級鎖)的副作用不容小覷，也足見原子變數屬實高效快速。

總結

本篇介紹了在解決執行緒競爭問題上最經常被使用的互斥子，學會了它的使用結構與邏輯，也認識到互斥子的使用所可能帶來的性能開銷。上鎖與解鎖互斥子由於牽涉到用戶態與核心態的切換、以及作業系統排程的參與，因此可能產生較長的時間延遲。這就是為什麼雖然互斥子的使用彈性相當大，開鎖與解鎖中間的程式碼可以包山包海，但人們有經常還是會在特定的地方更加青睞於只需要 CPU 指令排他、以及些許快取性能損失的原子變數的原因了。然而也同樣因為原子變數的使用限制大的因素，使得我們總還是經常不得不使用那些更高級的執行緒鎖(例如本篇介紹的互斥鎖)。因此在必須使用互斥鎖的情況下，通常我們會傾向於儘量限縮上鎖與解鎖中間的程式碼規模，只在臨界區域裡面執行真正需要受到保護的衝突內容，在得到通行權之後儘快處理玩事情並歸還通行權，減少其它執行緒不必要的等待時間。

1. 鏈結串列

執行緒同步 5：原子變數

Sat, 07 Feb 2026 20:39:21 +0800

上期我們看到當不同的執行緒彼此共同存取同一個變數的時候會發生什麼樣的異常結果，但是在現實中的程式裡又沒辦法完全避免掉共同資料的存取，那麼我們能夠怎麼辦呢？本篇就來介紹第一個幫助我們解決執行緒資料競爭問題的方案：原子變數。

如何解決資料衝突問題？

回顧前篇，我們知道不同的執行緒共同操作同一段記憶體資料會導致錯亂的問題，其原因有三：一個動作實際需動用多個指令來完成、由編譯器和 CPU 本身的亂序執行而導致的執行順序問題、以及 CPU 核心之間快取不同步，三者同樣都會導致最終不預期的異常現象。

為了解決問題，首先我們需要 CPU 本身提供能「原子操作」(Atomic Operation)的指令。是的，必須要 CPU 本身有提供這樣的能力。如果 CPU 沒有這類指令的話，那這個 CPU 就沒法用來做平行運算了，因為所有後面作業系統提供的那些更高級的功能都需要使用這些核心操作來實現。通常來說每個這種原子式的操作都只對應一個指令來進行，不像前篇演示過的一個加運算由好幾個指令組合那樣。原子操作指令只需要一個指令，畢竟只有一個指令的話，就不存在被其它指令從中間插隊的情形了！

再來，指令順序的部份也需要被解決，我們需要對那些關鍵性的資料操作行為設下一些關於指令順序調換的限制。我們需要要求編譯器不能那麼肆無忌憚的隨意調換程式敘述與編譯指令的位置，比方說在我們對那個關鍵的，也就是許多執行緒都會共同操作的變數(或記憶體區域)操作時，可能需要要求編譯器再怎麼最佳化調整順序，也不能把在此關鍵位置之前的讀寫操作調到後面去，或者將此關鍵位置後面的讀寫操作調換到前面。並且這項限制並不只是針對編譯器而已，考量到 CPU 本身可能有「亂序執行」的最佳化行為，因此同樣也需要 CPU 在執行原子類型指令的時候排斥、暫停其它指令的動作。而同樣的，這不能是另一個 CPU 指令，否則和前面的原子操作指令一前一後之間就存在了被插隊的風險，因此通常這個效果會被併入前面介紹的原子化指令中一步到位一起進行。

最後就是關於 CPU 核心的快取暫存的問題。如前篇解釋，CPU 的快取是為了減少與主記憶體的往來以加速資料存取及操作的目的地而存在。然而當一個 CPU 核心對資料進行修改時，這被更改後的資料可能會被留存在快取內而非立即寫回主記憶體，這就表示其它的 CPU 核心從主記憶體看到的並不是最新的資料；且如果它又對同樣的資料進行操作的話，那麼兩個版本的最新資料就這麼產生了！因此我們需要在進行原子指令的時候將修改後的資料立刻刷回主記憶體，並且同步去通知其它 CPU 核心，讓它們把我們正在操作的記憶體區段的快取(如果它們有的話)設為失效，這樣當其它 CPU 核心下回需要使用到那段記憶體資料的時候，就會被強迫重新從主記憶體讀出最新的數據。當然同樣的，相關的這些快取操作行為一般也都已經併入於 CPU 的原子化操作指令內了，這樣就能用無法被別人給插隊的僅僅一個 CPU 指令來一起完成上述的這些全部的動作。

原子操作的代價

既然原子式的指令這麼好用，可以直接解決多緒競爭的問題，那麼為什麼當今我們還要留著大量的普通指令，而不要全部使用原子化指令就好了呢？這是因為原子化的操作在解決競爭的同時，也是付帶著相應的代價的！

首先是對單一指令這件事。之所以平常的常規操作通常都需要搭配多個指令一起合作，那是因為許多複雜的工作其基底大多是一樣的，意思就是對 CPU 來說，提供幾個基本的磚塊就能讓我們使用疊積木的方式堆出我們想要的複雜功能。然而原子指令可好了，強迫 CPU 必須要一個指令做完一整個工作，於是 CPU 的設計複雜度和成本就無法節省了！這裡說的成本泛指一切的成本，包括售價、體積、功耗、與發熱量等。這就是為什麼 CPU 能提供的那些原子化的指令，通常都只能夠用來執行一些最簡單的功能的根本原因了，比如只能夠進行部份整數的加、減、值交換、及部份簡單的位元運算等。

此外，原子化的指令還需要對指令的排序做出限制，這會相當程度的影響程式的最終效能，無論是對於 CPU 還是對於編譯器來說都是。因為任何的順序調換行為其目的都是為了最佳化執行效率的目的，而當限制了能夠調整的空間，自然優化的效果就得受限了。然後每次的原子化指令操作還都得讓好多 CPU 核心丟棄它們相應的快取資料，使得如果原子指令操作的夠頻繁的話，CPU 就得不斷向速度慢了它自己一個等級的主記憶體頻繁讀寫資料，而這是導致原子化操作緩慢的主要因素！ (當然緩慢或快速都是比較出來的，如果是和以後要介紹的那些高級鎖比較起來的話，那麼原子操作還是非常快速的！)

範例

這裡讓我們繼續沿用前篇的範例，但是把那共同寫入的變數更改為使用原子變數(Atomic Variable)：

struct WorkData
{
    atomic_int value;
    int step_value;
    int proc_times;
};

在執行累加變數的執行緒函式內也需要修改，需要使用 C11 規範的原子變數操作函式來操作它：

int n = data->proc_times;
int x = data->step_value;

for(int i = 0; i < n; ++i)
    atomic_fetch_add(&data->value, x);

而在主程式內也同樣需要改用規範的函式來操作與初始化原子變數：

atomic_init(&data.value, 0);

//......

printf("Finished, value=%d/%d, spend=%u\n",
    atomic_load(&data.value), /*......*/);

原子變數與一般的普通變數不一樣，若直接把它當成普通變數那樣來做存取與運算，則並不能夠保證在所有的執行平臺上都能得到它應該產生的效果，因此正規的用法還是需要使用標準規範的操作函式來執行相關的操作。 C11 的原子變數支援的操作有加法(add)、減法(sub)、值交換(exchange)、位元與(and)、位元或(or)、位元異或(xor)、及讀值(load)與存值(store)等操作。就如同前面所說，原子變數能夠進行的操作運算真就不多！

完整的範例可以從這裡下載。在我的電腦上執行後的結果如下：

Finished, value=800000000/800000000, spend=5592

改用原子變數與操作之後，程式的計算結果終於正確了！然而，副作用也同樣明顯，程式的效能變差了！

相比於前篇範例程式的執行只消耗 1 秒多的時間，本篇改用原子操作之後的執行時間直接就拉到了 5 秒多，大約是原先的 5 倍。至於原子操作為什麼會慢的原因在前面都解釋過了，主要就是為了解決那三道導致資料競爭的問題。 CPU 原子操作本身就具有排他性，加上限制了 CPU 與編譯器的最佳化調配空間，然後快取又幫不上忙而需要去讀寫主記憶體，最種導致的結果就是肉眼可見的效能退化。只不過快與慢都是比較出來的，相比於後續介紹的各種執行緒同步機制來說，原子變數那可已經是最快速高效的存在了！了解這些事情後，落實在我們日常設計程式的工作中那就是要： 儘量避免設計出需要在不同執行緒之間大量讀寫共用資料的情況，並將執行緒之間共同交集的範圍縮到愈小愈好。 這樣我們才只需要針對最少量的關鍵資料進行特別對待處理，從而能夠最大程度的降低對程式效能的劣化影響。

Memory Order

在閱讀 Atomic Operation 相關說明文件的時候，通常會看到幾種 Memory Order 可以選用，那麼這些是什麼意義呢？我們又該如何選用呢？

前面提到了，原子操作其實相當影響效能(相較於非原子式的普通操作來說)，而效能劣化的其中重要原因來自於對最佳化能力的限制(無論是對編譯器還是 CPU)，那麼如果我們能夠視程式實際的情況去適度的放寬對最佳化的限制，是不是就能夠一定程度的提升原子操作的效能了呢？這就是不同的 Memory Order 所表達的意義了。當然如果選錯了 Memory Order，那可能就會導致如同前篇說明的那不讓人樂意的資料競爭結果出現。因此自認沒有把 Memory Order 完得很通透的作者我平常都只用條件最嚴格的預設值。

一般來說能夠選用的 Memory Order 有下列幾種：

Acquire

在這個執行緒裡，原本在這個原子操作後面的其它讀寫行為不能被重排序到這個原子操作前面；言下之意就是原來在前面的讀寫可以被重排序到後面去執行。並且其它執行緒如果對這同一個原子變數進行了 Release Order 的操作，那麼在那個執行緒做原子操作之前的所有資料寫入(並不限定於原子變數)立刻就可以被這個執行緒看見；因此 Acquire Order 通常被用來在讀取操作時使用。
Release

在這個執行緒裡，原本在這個原子操作前面的其它讀寫行為不能被重排序到這個原子操作的後面：言下之意就是原來在後面的讀寫可以被重排序到前面去執行。並且如果其它執行緒對同一個原子變數進行了 Acquire Order 的操作，那麼在這個執行緒的這個原子操作之前的所有寫入更新(並不限定於原子變數)立刻就能被其它執行緒看見；因此 Release Order 通常被用來在寫入操作時使用。
Consume

這個這定和 Acquire Order 基本是一樣的，用途也一樣，只是對於限制排序的讀寫操作僅作用於與當下這個原子變數的值存有關聯關係的其它變數 (因此通常這只對編譯器的最佳化行為有所影響)。
Relaxed

顧名思義，就是一種相當「放鬆」的操作。它只保證原子操作本身是原子的，但對於其它變數的讀寫操作排序什麼的就不做任何限制了！如果你的程式設計裡剛好只需要針對原子變數有所要求，而對其它變數的更新狀態無所謂的話，那麼就可以選用這個設定來嘗試獲得更好的效能。
ACQ_REL

就是 Acquire Order 加上 Release Order 的操作，既不允許在它之後的讀寫行為被排到它前面來，也不允許在它前面的排到它後面去。這通常被用在「讀取後更新再寫入」類型的原子操作，其實也就是大部份原子變數的計算操作行為上。
SEQ_CST

這是在 ACQ_REL 本身的基礎之上再加上更多限制條件的選項，也是在不指定 Memory Order 時的預設選項。我們說 CPU 的快取是因為讀寫主記憶體的緩慢而存在，但是過於頻繁的刷寫快取也被嫌慢，於是又整出了「準備等會要更新快取」的 store buffer 和 invalidate queue 出來！所以 SEQ_CST 就是在 ACQ_REL 的基礎之上，還要求 CPU 立刻馬上處理 store buffer 和 invalidate queue 不要拖。因此 SEQ_CST 就是所有 Memory Order 裡面對效能影響最大的一個，不過也是最為保險的一個，也是包含 C11 在那的大多數原子操作預設的選項，也是我通常不假思索就直接使用的選項。

Lock Free?

前面說明過，原子變數的實現需要 CPU 本身提供相應的原子操作指令，因此造成原子變數能夠進行的操作種類並不多的結果。然而另一方面，即便像是 C11 標準所制定的原子操作已經夠少了，但是有沒有可能存在某些 CPU 它們能夠提供的原子操作甚至還更少呢？甚至於，C++ 的 std::atomic 模板更加變態，還能讓你把所有任何物件通通變成原子的，你想想這怎麼可能呢？這些又是怎麼辦到的呢？

事實上就是許多 CPU 並不能夠提供 C11 想要的所有原子操作功能，因此可能會有部份的操作必須要讓編譯器去想辦法實現，而最終的辦法就是使用作業系統提供的高級鎖來實作這些功能。也就是說隨著我們的編譯與執行環境不同，可能有部份原子操作函式其實它底下並不是 CPU 的原生功能，而是藉由作業系統提供的功能來實現的。不論是 CPU 原生功能還是編譯器封裝作業系統功能的實現方式，最終都能讓我們的程式解決資料競爭的問題，跑出正確的結果，只不過效能可能會差很多！ 於是才有了判斷某個字面上的原子變數是不是 lock free 的相關函式。所謂 lock free 就是指對於這個型態變數的操作是 CPU 原生的，不需要動用到鎖(lock)；而那些不是 lock free 的，就是底層使用鎖(lock)等作業系統功能來實現的功能，是帶有較大性能開銷的假原子變數。

說到了 lock free，那就不得不提一個非常特別的原子變數，那就是原子旗標 Atomic Flag。這東西與其它型態的原子變數不一樣，它保證不管在哪一個平臺都是 lock free 的，都是使用 CPU 原生指令實現。之所以能做這樣的保證，那是因為即便是最陽春的 CPU，只要它能支援平行運算，那必定至少得實現最最最基本的這個指令，否則沒得玩了，因為所有後續更高級的作業系統相關的鎖的實現，都建基於這個最簡單的操作之上。作為所有 CPU 都俱備實現的原子操作的交集，這個 atomic flag 也是極其簡單，基本上它只提供兩個操作：第一個操作是設立旗標(設為非零)，並且傳回於本次執行前的舊旗標狀態；另一個操作則是無條件清除旗標。就只有這麼簡單的兩個操作，沒有別的了！

原子旗標的功能雖然簡陋，但是它保證肯定是 lock free 的。在極其陽春的環境下，光只要有這個功能，就能夠以它為基礎實現許多其它的高級功能。記得多年前我就曾在一個嵌入式設備的開發中使用過它。當時 C++11 才剛發佈，也就是說我們使用的編譯平臺根本還不可能用上這些新功能，甚至於我們當時還在使用祖傳的舊版本 GCC，連編譯器的 builtin atomic 都還沒有支援，然後就這麼剛好的我需要在這樣的情況下解決一些執行緒競爭的問題。於是我在那個時候就去翻找了 ARM CPU 的指令集(那個時候的 ARM 指令集還相當簡單，不像現在的複雜)，找到了一個 atomic value exchange 的指令，然後用組合語言寫了上面所描述的兩個 atomic flag 的操作函式，再用這兩個函式手搓了一份簡單但能用的執行緒鎖(mutex)，如此解決了當時的問題。當然以當前現在的開發環境來說應該是不太有需要再去做一次這種事情，但是當時的經歷還是能讓我覺得挺有意思的！

結語

本篇介紹了能夠解決執行緒資料競爭問題的第一個解決方案：原子變數。原子變數是所有執行緒同步機制當中最簡單高效的一種方案，然而它也同樣帶來一些副作用，在解決競爭問題的同時給效能帶來劣化的影響，因此在使用原子變數的時候也並不能夠過於肆無忌憚。

執行緒同步 4：為什麼出錯？

Sun, 01 Feb 2026 20:16:12 +0800

經過前面幾篇，想必讀者已經對執行緒與其運作原理有了一定的認識，也能夠自己動手開始製做多執行緒的程式了。但是當真正開始嘗試以後，應該很快就能發現一些奇怪的現象。比如有些執行緒共同存取的變數好像偶爾會冒出怪怪的結果，而如果共同存取的是一些比較複雜的物件如標準函式庫的容器等等的話，可能還會冒出各種奇奇怪怪的異常或甚至導致程式當掉等等問題。那麼這是怎麼回事呢？為什麼會出問題呢？

Race Condition

這種在多緒程式所容易產生的資料存取問題被稱為資料競爭(Race Condition)。接下來讓我們使用一個範例來呈獻這種問題。

下面是我們的執行緒函式，它的行為就是使用迴圈不斷將一個變數的值進行累加：

struct WorkData
{
    int value;
    int step_value;
    int proc_times;
};

static
int ThrdFunc(struct WorkData *data)
{
    int n = data->proc_times;
    int x = data->step_value;

    for(int i = 0; i < n; ++i)
        data->value += x;

    return 0;
}

然後在主函式內建立 4 條同樣執行上面那個函式的執行緒，並且傳遞給它們同一個資料結構，這樣它們就會一起對那同一個變數進行不斷累加的行為：

struct WorkData data =
{
    .value = 0,
    .step_value = 2,
    .proc_times = 100000000,
};

static const int thrd_num = 4;
thrd_t thrd_list[thrd_num];

for(int i = 0; i < thrd_num; ++i)
{
    int err = thrd_create(&thrd_list[i], (int(*)(void*)) ThrdFunc, &data);
    assert( err == thrd_success );
}

以上只顯示了關鍵重要的程式碼片段，而完整的範例可以從這裡下載，而在我的電腦上實際執行過之後的結果如下：

Finished, value=344688372/800000000, spend=1176

從上面的程式碼中可以看到，指定給迴圈的循環次數是 100000000，也就是每個執行緒都會跑過 1 億次累加計算。那麼那個共同累加的變數初值為 0，每個執行緒累加 1 億次，每次累加值為 2，又總共有 4 條執行緒一起工作，因此最終計算完成的結果應該是 8 億；然而實際執行結果卻只有 3 億多，這是怎麼回事呢？！

為什麼出錯？

當不同的執行緒共同讀寫同一個變數，或者說共同修改同一段記憶體的資料時，就會發生資料競爭的情況，從而有機率導致發生不可預期的資料異常情況。導致這種結果發生的原因主要有三：多指令工作、核心快取、以及執行順序所導致。

多指令工作

除非是系統性修習過資工專業，或是從電子電機相關領域念上來的人，否則對於一般直接從高階程式語言入門學習的人來說，應該一般不容易很快的理解到即便是一個看似簡單又單純的程式敘述，其背後往往需要動用好多條 CPU 指令來完成。例如上面的範例程式碼，在執行緒函式中對那個 value 變數所進行的 data->value += x 這一條看似簡單無比的敘述，背後真正完成這項操作的其實是以下數個指令的結果：

movq	-24(%rbp), %rax ; 將 data 資料結構的地址讀入 RAX 暫存器
movl	(%rax), %edx    ; 將 data->value 的值讀入 EDX 暫存器
movl	-4(%rbp), %eax  ; 將 data->step_value 的值讀入 EAX 暫存器
addl	%eax, %edx      ; 將 EAX 與 EDX 的值相加，並將結果存回 EDX 暫存器
movl	%edx, (%rax)    ; 將 EDX 的值存入 data->value 變數內

上面的指令呈現只是作者在我的電腦上編譯出來的的結果，而讀者如果自己在家裡嘗試編譯範例程式碼的話，可能產生的結果會有些許不同。這是因為不同的 CPU 所使用的指令集並不相同，或者使用不同的編譯器與不同的編譯條件可能也會產生不同的指令的緣故，然而具體細節雖然可能有些差異，但是指令結構基本大差不差，並不影響本篇敘事的邏輯和原理。

你看啊，這一個動作有這麼多的步驟要進行；可如果命令進行到一半還沒全部做完的時候，執行緒就被排程器給切走了，那會發生什麼事？！比如一個執行緒拿到那變數的值是 6，然後加 2 變成 8，再把 8 給存回變數。但是在這個過程中可能執行緒自己曾經被切出去又切回來，其它正在執行同樣事情的執行緒可能已經做過一次拿到 6 後加 2 再將 8 存回去的步驟，但是這個執行緒並不知道這件事，於是就把它自以為已經累加過的，但實際上也同樣是 8 的數字給覆寫回去了。導致雖然兩個執行緒都做過一次累加，但實際結果卻相當於只做過一次累加！甚至於，執行緒切出去又切回來的時間內，搞不好其它執行緒已經執行過好幾回累加，而那個數字可能實際已經變成 22 了；然而當這個執行緒重新被切回來的時候，剛才發生過的這些事它當然都不知道，於是又把它認為計算後的新值也就是 8 給覆寫回去了！

這就是為什麼執行緒共同存取覆寫資料的時候會導致競爭衝突的原因其一。也許你會認為這問題是出在於執行緒切換的時間點不太好導致的，如果讓排程器可以不在某些事情做到一半的時間點去切換，而是能讓同一組相關的指令執行完在切換的話就能解決問題；然而這個想法實際可行性並不高。且先不論這會導致排程器的排程運算複雜到什麼程度，能不能夠被實現出來等問題，即便排除萬難把能辦到這樣條件的排程器給造出來了，別忘了還有多核心、多 CPU 的情況，它們可是真實的同時在平行運作的呢！甚至還可能每一條指令剛好都同時在進行的呢！

Figure 1. 左邊是單執行緒進行 4 次累加，解果正常且一如預期；右邊則是 4 條執行緒在可能任意的時間進行累加的結果，就發生了新舊狀態互相覆寫的情況！

核心快取

在前篇曾經解釋過，我們人在工作的時候往往會先把一些會用到的資料從櫃子裡拿出來放到書桌上，這樣即時要用的時候就可以直接轉頭到旁邊翻找參考，而不用一直來來回回去書櫃那裡，而 CPU 其實也是一樣的！電腦的主記憶體對 CPU 來說其實相當緩慢，因此 CPU 內部每個核心也有一份自己的小記憶體，就像你桌面的空間不如書櫃那麼大，但是操作起來可快了，這東西就被稱為「快取」(Cache)。每當需要參用資料的時候，CPU 並不會每次都去主記憶體索取，而是如果快取有資料的話就會直接和快取要。相對的，每次覆寫資料的時候也會先寫到快取內，後續等到合適的時間才會把快取更新的資料寫回主記憶體。

但是問題就來了，當系統存在多個 CPU 或多個核心的時候，每個核心自己算自己的快取資料算的很開心，但是如果別的 CPU 核心其實也在自己的快取裡面修改這個「理論上應該是同一個變數但實際上各核心自己有一份快取副本」的資料呢？於是有一部份的資料衝突就有可能來源於這裡了！然而這裡說的可能，那是因為源自於快取問題其實 CPU 本身的協作機制(通知快取失效) 就已經處理掉了大半，僅剩一部份還需要在後續的操作中加點料，而這一部份我放到下一篇再談。

執行順序

你知道嗎？雖然我們一般認知程式都是一行一行的往下執行的，並且在學習的時候也是被這麼教導的，然而實際上的程式並非如此！比方以下面這一段程式碼為例：

e_b = e_i + e_u;                    // Line A
v_i = w * r * sin(e_i) / cos(e_u);  // Line B
v_i_x = v_i * sin(e_b);             // Line C
v_b = w * r * cos(e_i) / cos(e_u);  // Line D
aoa = b - e_b;                      // Line E
cl = calc_cl(r, aoa);               // Line F
cir = 0.5 * v_b * c * cl;           // Line G
tlf = (2/PI) * acos(exp(( -k*( 1 - 2*r/dia ) )/( 2*sin(b_tip) )));  // Line H

為了方便講解，上面這段程式碼的每一行註解都加上了 A~H 的標號。就看上去的理解，這段程式碼的執行順序應該是 A → B → C → D → E → F → G → H，然而實際上的執行順序卻可能是 D → F → B → A → G → E → C → H、或者可能是 H → F → B → D → A → C → G → E，或者還有其它更多可能的排列組合。那麼為什麼會有這種情況呢？答案是為了編譯最佳化(Compiler Optimisation)！

舉的例子，比如你媽要你去幫忙買個菜，回來的路上順便幫忙去繳個費，回來之後順便洗兩杯米煮個飯，然後再出門幫媽媽把醬油還給對面的王阿姨。這時我們就得到了一份指令清單，然而當落實到了實際的行動時，我們卻很可能會調動這份清單的執行順序，而並不一定會嚴格的按照所交辦的順序。為什麼呢？因為我們懶，想要省點事！比方考量到買好了菜以後，回來的路上可能要背著一大堆東西去繳費好像不是很方便，於是我們可能會選擇在去程空手的路上就先把費給繳了；比方煮米這件事相當消耗時間，我們可能會選擇最先執行這件事，這樣在等會出去的時間裡正好讓電鍋同步在煮米，而不是讓電鍋空等到我們回來之後才開始下鍋煮；又比方說我們可能不想要出門兩趟，於是就選擇在煮好米之後出門先把醬油還給對面王阿姨，然後去繳費，再買菜。

上面這個例子放到編譯器上面其實也是一樣的。編譯器可能會有自己的想法，它可能會把你的程式敘述調換排列的順序，因為它認為這樣可以進行的更快速更順暢；反正不論編譯器怎麼調換排序，只要最後執行出來的結果和嚴格按照順序執行出來的結果一樣就可以了！於是回顧上面的範例片段，八行程式碼可以被編譯器隨意調動，除了行 C 和行 E 不能被調到行 A 前面，因為那兩行的計算都需要依賴行 A 的結果；同樣的，行 B 怎麼調都可以，就是不能調到行 C 前面，而行 G 必須在行 D 和行 F 的後面等；甚至於計算最複雜的行 H 竟然不依賴前面任何一行的結果，於是可能反而第一個被送去執行等等。

程式指令這樣順序換來換去可能可以更高效的被執行，反正只要結果和沒換順序時一樣就可以；然而當多緒同步運作的情況下，問題就可能產生了！那些執行緒各自參照和共同參照的變數的存取覆寫順序可能有所不同，在單緒條件下反正最終的結果是一樣的，然而在多緒平行互相參雜的時候，就可能因為執行緒之間原本就存在的互相截獲干涉等因素，而導致對結果產生不可預期的結果偏差錯誤！也許我們可以透過一些編譯器選項去禁止編譯器重排指令順序，然而這個問題依然可能會發生，因為指令即便按照順序送給 CPU，CPU 卻也不一定會按照順序處理！這就是 CPU 的「亂序執行」(Out-of-Order Execution)功能，其同樣也是因為不同的指令可能需要消耗的資源與等待等不盡相同，因而同樣 CPU 為了最佳化指令處理流程而自己做的優化。

這就是為什麼在多緒程式裡只要共同存取變數就可能會導致異常的三個原因。在處理資料與數字計算等應用下，它可能會導致計算結果的偏差錯誤；而如果共同存取的是一些比較複雜的並且涉及記憶體管理或系統資源管理的物件，比如對標準 STL 容器的操作，則可能導致其內部狀態錯亂、違規存取，從而導致行程崩潰的結果！對於這些問題當然存在許多解決方案，但是本篇只專注於解釋導致問題發生的原因，因此那各種的執行緒同步技巧與方案等，就留待後續的篇章慢慢講解了。

為什麼多緒程式難？

不知道現在這個世代還有沒有人曾經被學長、前輩給恐嚇過類似像「千萬不要嘗試多緒」、「多緒是非常難的東西」、「能單緒就只用單緒就好」、「沒事別搞死自己」這樣的諄諄教誨耳提面命？對於特別是對於包括作者本人在內的，那些並未經受過紮實數位工程基礎訓練的半路出家程序員來說，多緒程式確實存在許多令人摸不著頭腦的，讓人想不清原因的，又如午夜精靈那樣忽隱忽現的各種奇異又詭異的問題。那麼為什麼多緒程式就這麼多問題，這麼容易讓人感受到挫折呢？其實一言以蔽之就一句話：極強的隨機不確定性！

對於那些程式邏輯錯誤的查找工作(也就是程式「除錯」，或俗稱「抓蟲」)，其實通常來說害怕的並不是錯誤的嚴重性。因為哪怕是天大的錯誤，只要它每次必然發生，或只要經過同樣的操作步驟之後必然觸發，那就都不是什麼大事，錯誤被定位然後被解決都只是板上定釘的事情。真正讓人感到頑固討厭、如貓捉老鼠那樣摧毀人心態的錯誤，是那種忽明忽現、抓不到規律、摸不清底細，你要抓它的時候守候整夜都不出現，你放棄的時候客戶又告訴你它出現了的錯誤；而與執行緒有關的錯誤經常就是這一種型態！

經過本篇解釋到這裡，應以明白執行緒之間容易出的狀況主要在於執行流程的互相插斷、干涉。然而這種影響卻是隨機的！這次因為執行流程剛好斷在某個位置、或剛好在執行到某個位置的時候也恰好某另一條執行緒剛好執行了哪個動作，於是導致現在出現的某個問題；但是，同樣的問題卻很難重複顯現，因為我們基本無法控制不同流程之間的斷點情況。也許下一次執行，剛好程式流錯開了，就沒發生任何問題；或也許下一次執行遇到的是另一種執行情況的排列組合，顯現的是完全不一樣的另一個狀況；甚至於，作業系統排程也在問題出現與否的行為中扮演關鍵性的角色，畢竟所有的執行緒斷切回復全都是它在控制的！意思就是說，甚至執行緒有關的問題出現或不出現、或者是呈現樣態的不同，已經跳脫你的程式本身了，而是整個系統上所有正在運作的其它行程、以及作業系統本身的狀態通通都會影響進來，可能每次執行出來的效果通通不一樣，每次出現異常的程式位置到處跳來跳去等；或可能更加讓人惱怒的情況是重複執行一百遍通通剛好沒問題，然後在執行一萬遍之後才剛好抓到它那麼冒頭一次！

說了那麼多，那落實到實際的程式設計之中要怎麼樣去避免產生這些問題呢？其實本來就應該要有的清晰的結構設計和模組責任劃分與內外區隔等設計原則，其本就可以很大幅度的降低執行緒之間互相會產生交互作用的涵蓋範圍。然後建立在前者之上，我認為最重要的一點原則就是 嚴格審視多緒交互影響範圍的邏輯程序，確保邏輯嚴謹；並且 絕不心存僥倖，只要一個有疑慮的情況有發生的可能性，哪怕你覺得只有怎樣低的發生機率，也必須要處理掉！

上面的第二點尤其更加重要，切勿存僥倖之心。這怎麼說呢？如果你把範例程式碼的循環次數改成比如說 5 次或 10 次之類的就能感受到了，可能絕大多數時候執行出來的結果都是一切正常！說實在這些問題的發生是非常吃機率的，因此實際上很可能程式執行過有問題的程式碼非常多次卻都剛好沒有遇過問題；然而機率低不表示絕對不會遇上，只要把程式放出去大量使用，那麼問題就總是會發生！並且現實上真出問題的機率愈低的那種問題往往才是最討厭的問題！所以有些時候特別在當我們寫程式寫累了的時候，可能看到一段程式碼思索一下覺得或許哪個地方存在多緒交互運作之下邏輯不夠嚴謹的疑慮，這時可能就容易懶下來，可能會產生「不會這麼巧吧？兩個操作也就一前一後的兩個連在一起的敘述，得要多麼湊巧才會讓執行緒的切換正好斷在這？」這樣的取巧心理。然而這就是危險的地方，因為如同前面說過的，機率即使再低，只要放出去大量執行就一定會遇上；並且就是因為遇上這種問題的機率真的特別低，於是它很可能就會成為往後不知何時何日將你絆在辦公桌前幾個星期找不著北的罪魁禍首！

關於範例程式

本篇所使用的那個累加數字的程式其實已經爛大街了，幾乎是所有論述到執行緒資料競爭話題時都會出現的程式碼。我在寫作本篇的時候本來也想說是不是拿個更加實際一點的、更加有用點的程式來作範例，然而找了一圈最後還是使用了這個最經典的累加程式。

主要的原因如同本篇後面所論述的內容，現實當中的執行緒衝突其實通常並不容易發生，往往要累積執行次數與量之後才能靠著機率遇上一兩次。然而作為一個示範則訴求卻剛好相反，如果我說「你就拿去每天早上起來的時候都跑一遍，一個星期應該會遇到一回」，或者說「每兩個小時就執行一遍，這樣一天應該有機會遇上一次」的話，那麼這顯然不是一個好的示範程式，而在這種情況下的一個所謂好的示範程式，就應該要能夠在每次執行的時候都能曝露問題。這就是為什麼這個範例程式需要使用迴圈連著執行同樣的動作一億次的原因了。而在我寫作本篇時自己的測試中，當迴圈次數少於一百次的時候，就已經幾乎不能夠顯現問題了！

而為什麼思來想去我最終還是沒有使用更加有趣的計算程序，而還是回歸到累加計算呢？因為作為示例程式其實還有一個也同樣重要的優求：要能夠明顯看出問題。那麼要讓我們能夠明顯察覺異常，顯然就需要有一個很明顯正確的結果來作為對比，而累加算法正好就是那種可以讓我們即便不執行程式都能知道它正確的結果應該要是什麼的算法！

最後還有一個相當重要的東西，如果讀者想要把範例程式拿到自己的電腦上編譯執行做測試的話，麻煩一定要調整你自己編譯器的設定，然後將編譯最佳化給關掉！ 編譯最佳化就如同本篇前面解釋過的執行順序最佳化的那部份一樣，是編譯器可能覺得你寫的程式碼囉唆，於是它調整了你的程式碼，試圖取得更快的執行速度。並且這種編譯最佳化行為並不僅止於如本篇所述的調整你的程式執行順序而已，它可能還會濃縮、展開、刪除、變更、改寫你的程式碼，反正目的就是盡可能找出某種方式給你的程式改頭換面，雖然可能把內容改變了十萬八千里，但最後出來的結果和忠實呈現不動你程式碼的話出來的結果一樣，並且還更加快速省事。然而對於本篇範例程式碼來說這並不是好事，因為範例其實是一個實際應用中真實情況的簡化演示，但是可能因為過於簡化了，導致編譯器覺得「你寫這東西怎麼這麼蠢啊？改成這樣這樣，你看不是一下就出來了嗎！」最後反而重現不出我們原來所預期的效果。比如我在做測試的時候就曾嘗試把最佳化開到最大，結果程式休一下零秒就跑完了！(原來需要一秒多！) 一看編出來的結果，原來是編譯器覺得我用迴圈一次一次累加一億次太蠢太費事，於是它直接改成了 data->value += 2 * 100000000；雖然就結果來說它做的相當好，但反而在本篇的訴求上就完全不是想要的效果！

因此如果你想要自己編譯執行本篇範例，請記得關閉你的編譯器的最佳化編譯功能；如果你使用的是 GCC 的話，那麼可以加入編譯選項 “-O0” 來關閉最佳化。此外，如果你想要觀看編譯器編譯後真正送去執行的東西的話，可以設定將編譯器編譯出組合語言這個步驟就停止並輸出。組合語言雖然還不是機器碼，但與機器碼之間基本絕大部份都是 1:1 直接對應的，因此對於分析理解的用途來說已經相當於直接閱讀機器碼了！然而可能並不是每個編譯器都支援把程式碼編譯成組合語言並輸出的功能，但如果你使用的是 GCC 的話，那麼加入 “-S” 編譯選項就可以做到這件事，並且本篇所使用的組合語言分析也都是這麼得來的！另外，不同 CPU 的指令集可能並不相同，因此如果你不是在 x86 電腦上去編譯組合語言的話，可能會看到與本篇示例差異巨大的結果，但這都是正常的現象。

執行緒同步 3：任務、執行緒、行程、與程式

Wed, 28 Jan 2026 23:07:51 +0800

在解釋明白了作業系統實現多工的原理後，本篇要來整理一些與執行緒相關的常用名詞解釋，特別是那些一般可能容易混淆的名詞與含義。

指令與任務

首先來解釋「指令」(Instruction)，或者有些地方叫作「機器碼」(Maching Code)。指令是 CPU 真正能夠讀懂並且知道要去做什麼事的命令碼，是電腦 CPU 硬體實際上真正一個接一個不斷執行的命令，也是我們的程式最晚到了執行之前要變成的東西。而「任務」(Task)，就是一群為了共同的目標而生，服務於共同目的的多個指令的集合。只不過光有任務是遠遠不夠支持一個程式的執行的，因為程式的執行並不只依靠命令口令，還需要許多使它能夠工作的相關資源，因而才有了執行緒；不過關於執行緒我們先暫時放著，先來看看行程。

行程與執行緒

「行程」(Process)是電腦作業系統裡一個真正完整的具有執行狀態的程式。行程裡面當然內含了上面所說的任務，可能還不只一個(只不過通常不會以裸裝的任務型態存在)。然而行程所擁有的並不只是一大堆的指令。一個行程裡面還包含了程式執行所需要的各種資源，例如記憶體空間、程式計數器與各種暫存器空間、堆疊空間、資料空間、系統與檔案資源等等。由於行程包含了一個獨立程式執行所需要的完整資源，因此行程也被稱呼為一個程式在作業系統內存在的完整實體。

如同前面說過，任務作為指令的集合其本身並不完備，因為還缺少了真正能夠「執行」起來所必要的一些資源，於是通常除非在討論排程器這樣的話題裡，否則通常不容易看到任務這個名詞被提起。因此在作業系統內真正能夠被安排與調動的最小單位其實是「執行緒」(Thread)。執行緒不像行程那樣包山包海的完整，而僅只有一些能夠支持它正常執行運作所需的最小資源集合，因此執行緒並不能夠獨立的作為一個執行實體存在於系統內，而必須依附於行程；或者可以說，執行緒其實就是任務加上所必須的執行資源後所成的包裝，因此它的完整性介於任務與行程中間。

於是這裡總結一下，行程就是在系統內完整獨立的單位；而一個行程內部會擁有至少一個執行緒，作為能夠執行與被排程的單元。單獨的執行緒本身並不足夠完整以致於能夠獨立的存在和運作，執行緒需要依附於一個行程以使用其之資源，並且屬於同一個行程內的所有執行緒皆共享行程內的資源，而這也是為什麼我們前篇範例內的執行緒可以共同存取記憶體變數等資源的原因。然而行程並不只是擁有完整資源的獨立存在而已，它還被作業系統給設法限制與保護住，因此不同行程之間彼此是獨立的，行程之間(正常情況下)沒辦法存取、利用、與窺探另一個行程的內部資源。 這也是為什麼通常來說我們電腦上的一個軟體當掉之後並不會影響其它軟體與系統，並且我們還能夠單獨殺掉那個異常的行程的緣故了！

不過在古時候作業系統對行程的保護與隔離還沒那麼完善的時候就不是這樣了。那個時候的電腦如果有一個程式寫不好，違規存取它不該取用的資源，或者它自己異常死掉了，是可能會造成其它原本正常的程式也發生異常，甚至能把系統也搞到異常當掉的！當然好處也是有的，在那個時代不同的程式之間要傳遞消息互相溝通就想當方便。反正我對你的內部能看能拿，並且你對我也是，那麼什麼資料我就可以隨意塞給你，你也可以隨意塞給我。而到了現代的行程之間被隔離獨立，還要再能互相溝通的話就只能依靠「行程間通訊」(Inter-Process Communication (IPC))的手段了。

執行緒的獨立與共用資源

回到執行緒身上。同一個行程內部的所有執行緒原則上共享所有的資源，然而有些資源還是不能夠共用的，必須執行緒自己擁有一份。作為一個能夠獨立被 CPU 排程器調派並執行運作的單位，不同的執行緒之間除了各自擁有各自的指令之外，顯然那些與執行有關的上下文狀態就沒有辦法共用，因為不同的執行緒彼此的執行狀態並不相同。具體來說，這些執行緒必須自己擁有一份的資源有像是：程式計數器(Program Counter)的備份、各 CPU 暫存器(Registers)的備份、以及堆疊空間(Stack)等；至於像堆積空間(Heap)、全域空間(Global)、檔案與各種系統資源等，則所有執行緒共用同一個行程裡面的這些資源。因此在前篇的範例中數個執行緒才能夠直接取用共同的全域變數。不過同一個行程裡面的多個執行緒僅僅只是擁有一份屬於自己的資源而已，並不像不同行程之間會受到作業系統的隔離保護，因此執行緒之間是可以存取彼此的資源如堆疊空間上的變數等等，只要你知道那些東西的位址在哪裡就可以了。

上面解釋的方式比較中規中矩，但是怕可能許多並沒有那麼多資訊工程背景的程序員們可能會像在看天書，於是這裡用更加白話而貼近程序員日常的語言再解釋一遍。濃縮總結最重要的部份其實主要在於記憶體空間的分配上。全域空間(Global)，也就是宣告為全域變數、或者是函式、類別內的 static 型態變數，都是整個行程裡面只有一份的，任何一個執行緒改寫了變數的值，則所有參用到這個值的其它執行緒都會受到影響。堆積空間(Heap)，也就是我們在程式裡面透過 new、malloc 等操作所動態建立的空間，也是所有執行緒都可以直接使用的，並且一個執行緒建立的空間由另一個執行緒進行釋放也是可以的(至於合適不合適這麼做，就要看程式的設計結構了)；並且一個執行緒釋放了一個堆積上的空間後，其它執行緒再嘗試存取就屬於違規存取了！最後是堆疊空間(Stack)，就是函式內的區域變數，讓函式可以層層呼叫甚至嵌套呼叫的基礎，於是這個堆疊空間便是每一個執行緒獨立擁有一份的。意思就是同一個函式內的區域變數在不同的執行緒執行之下，彼此是獨立且互不相干的，這個執行緒怎樣操作區域變數並不會影響另一個執行緒；但是執行緒各自擁一份區域變數空間並不表示彼此被完全相互隔離，一個執行緒仍然可以將它堆疊空間內的變數位址傳遞給另一個執行緒去做參用或修改，並且雙方都能看到被修改更新後的內容。

不過這裡再補充一點知識，以上的定義與區分是屬於邏輯概念上的東西，但是個別作業系統的實現方式與細節可能仍有所不同。比方說 Windows 的實現方式就與前面的解釋內容一樣，行程裡面包含執行緒，因此每一個行程至少都會擁有一條執行緒。而 Linux 就沒有獨立的執行緒實現，而是設計無論執行緒還是行程都是一樣的東西。在 Linux 裡只有行程，一條邏輯上的執行緒其背後其實是一個行程；一個行程裡面也沒有再包含一個執行緒，因為它本身自己就是。對於 Linux 來說，一切都是行程，只不過是有些行程之間是共用部份資源的，有些行程之間是存在父子關係的，僅此而已。然而不論個別作業系統對這些功能的實際實現方式如何，在外顯的運作邏輯與特性上都符合本篇所講述的結構，因此我們站在應用程式的視角其實可以把這些細節看作為實作方式的不同就行了。

上下文切換

我們知道當代的分時多工作業系統依靠一個排程器在多個執行緒之間不斷來回切換執行，營造出好似大家同時執行的效果 (當然在多核或多 CPU 情況下還真的會有那麼幾個執行緒能真正意義上的「同時」執行)，但是這種執行緒之間的來回切換並不是沒有代價的！

每一個 CPU 核心一次只能執行一條任務，每一條執行緒都有自己獨立的執行狀態，而每一個執行中的任務其實都有許多正在臨時使用中的執行資源。比方說當我們在辦公室埋首處理各中文件資料與公文時，或者當我們在書桌前認真研究什麼東西時，我們通常不會乖乖的在需要參考使用資料時才站起來去到書櫃或檔案櫃那裡拿取，而是會預估並取出某些可能會需要即時參考的資料到書桌上，一邊工作一邊參考，工作做完了或告一段落了才會把東西放回去。甚至於我們可能會臨時隨筆寫下一些幫助短期記憶，比方說現在讀到哪裡，剛剛參考的是哪本書第幾頁，臨時想到什麼怕等會忘了於是寫下來的便簽等等。這些東西在電腦、CPU、與作業系統中同樣都存在，比方說像是程式計數器和各種 CPU 暫存器等等，甚至於某方面來說 CPU 快取也能算在其中之內，而這些就統稱為執行條件的「上下文」。

當我們的作業系統要切換執行不同的執行緒時，就會需要先把當前執行的這個執行緒的相關資料、狀態數值等先保存在執行緒的相關備份區域內，然後再把要切換過去執行的那個執行緒的相關狀態從它的備份區域讀出來並取代當前的執行上下文，然後才真正開始執行那個要切換過來的執行緒的任務。因此這樣的行為就被稱為「上下文切換」(Context Switch)，而閱讀過前面的描述之後，想也知道這樣的上下文切換需要花費一點時間。雖然上下文切換的速度相當快，但如果過於頻繁切換的話也會導致效能有所降低。因此作業系統排程的時間片(Timeslice)如果設計的過短也會導致過於頻繁的進行上下文切換，從而導致效能受損；同樣也是當我們對程式的效能有些刁鑽的時候，有些時候檢討並儘量減少上下文切換的機會，在某些時候也是能夠提升程式計算效能的其中一處入手點。 (不過雖然說是這麼說，但這裡還是建議程式小白先不要想那麼多，看過就算了。 因為很多時候當了解掌握還不夠熟悉的情況下，很容易弄巧成拙！ 只需要先當了解一個冷知識那樣知道有這麼件事存在就可以，等你的火候足夠的時候自然會了解領會過來。)

程式

最後再來題一個東西叫作「程式」(Program)。程式這東西有點意義不那麼明確，因為口語上其實許多應該被叫作行程的東西會被我們稱呼為程式，比方「電腦後臺管理器看到有個程式在跑」之類，然而這裡我要說的是嚴格意義上的「程式」(Program)。

一個程式其實就是一堆死的資料，通常以一個執行檔檔案的型態存在，也就是我們撰寫的程式碼編譯(或稱建置可能更合適)後所成為的東西，那個叫作程式。那麼當我們要執行一個程式的時候，作業系統就會去讀取這個檔案，按照檔案內所記載的內容將指令資料讀入記憶體、規劃記憶體空間、配置需要的系統資源，並初始化各項資源後成為一個系統內的行程，然後從第一個指令開始執行。也就是說，系統內真正能夠執行運作的實體仍是行程，而程式則是告訴系統如何建立產生一個用來執行特定任務的行程的規格書。

這就是為什麼明明只有一個「小畫家」程式，我們卻可以重複啟動好多次，讓桌面上同時開啟好幾個小畫家程式(行程)，且每一個程式(行程)所載入編輯的圖檔都不一樣，彼此之間完全獨立不互相干擾。這時桌面上存在的好幾個小畫家的畫面，其實就是一個一個各自獨立的行程實體，而這些行程全部都來自於同一個「程式」。

執行緒同步 2：多工原理

Mon, 26 Jan 2026 00:12:16 +0800

本篇要來解釋電腦能夠同時進行許多程式的多工原理，這對於我們進一步認識系統機制，以及了解後面介紹的各種執行緒機制相當有幫助！

現代的我們可以同時執行好幾個程式，一邊聽音樂、一邊上網追劇、一邊和好友網路聊天等等，可以同時執行好多個程式。就算是我們自己寫的程式，也可以要求啟動好多個執行緒分頭行事。然而這種我們現在覺得司空見慣的電腦「多工」能力其實並不是與生俱來的。曾經的早期電腦一次只能執行一個工作，放音樂的時候就是單純放音樂，要打字寫文章的時候得先把音樂給停了才能做，反正任何工作都只能夠一次一個的進行，直到多工機制被發明以前。

那麼電腦是如何讓多支程式能夠同時執行的呢？有些小伙伴也許可能會喊出：「我知道！那是因為現在的 CPU 有好多個核心的緣故，每一個 CPU 核心都可以執行一個程式，好多個核心就可以執行好多個程式了！」這麼說好像也沒什麼問題，而且事實上多核心乃至多 CPU 確實可以增進多工的能力，然而電腦(或者更確切的說是作業系統)卻並不是依靠多核心或多 CPU 來實現多工能力的！比方說也就大約 20 年前的電腦 CPU 普遍不是多核的，都是單核的，但是那時候的電腦仍然能夠同時執行成百上千的程式。即便是多核 CPU 已經相當普及的現代，打開你的任務管理器，數數看你有幾個 CPU 核心？一般現在通常大約是在 4 個到 32 個之間吧。然後再數數看電腦後臺現在有多少支程式正在運作？以一般家用系統來說，掐指一算可能都有上百個後臺程式。於是你會發現到一件事，如果多工的功能是依賴多個 CPU 的核心或者多個 CPU 裝置來實現的話，那麼這多工的能力是遠遠無法應付這麼數量龐大的程式同時進行的！那麼現代的電腦(作業系統)到底是如何實現多工機制的呢？

分時多工

Figure 1. 同步處理 3 個工作任務(Task)的執行示意

現代大部份的電腦作業系統採用的都是「分時多工」(Time-Sharing)的工作調度模式。如上圖(Figure 1)以同時處理 3 個任務的情形為例，每一個顏色磚塊代表一個工作，也就是一個 CPU 指令。這裡的「指令」(Instruction)就是 CPU 能看得懂的指令碼，是真正能讓 CPU 知道該去幹什麼事的實際命令，也就是我們的程式碼語言在經過編譯之後會變成的一連串二進位指令碼。那麼一個工作任務(Task)就是一串指令碼的集合，而這的例子就有 3 個不同的任務要進行。那麼我們的作業系統就會把這些指令拆成一段一段的，先分出一小段時間去執行其中一個任務的指令 (這個一小段時間被稱為「時間片」(Timeslice)，通常來說是大約幾個毫秒左右)，然後就暫停這個任務並切換去執行另一個任務一小段時間，然後再切換執行另外一個任務，以此類推……。就這樣，即便電腦可能只有一個 CPU 核心，也可以像影分身術那樣不斷在多個任務中切換，雖然嚴格意義上來說在同一個時間裡 CPU 還是只能做一件事，可是因為每一個任務一次執行的時間相當短暫，一般通常大約在數毫秒左有，使得我們在感知上覺得好幾個任務是同時在進行的。這就是分時多工的基本原理。

以上是單 CPU 核心，也就是同一個時間裡只有一個人(CPU)能做事情的情況，但是若再進一步擴展到多核心乃至多 CPU，其實原理結構也還是一模一樣的，只不過這時候在同一個時間裡，就真的是嚴格意義上的可以同時執行兩個任務了。如同下圖(Figure 2)就是同樣 3 個任務只不過改由雙核心 CPU 來處理的情形示意，然而再繼續擴展成更多核心數的話也是一樣的，總之就還是同樣的多任務輪流切換執行的結構，只不過這次不是一個人(CPU)，而是兩個人可以同時分擔消化要執行的任務群。

Figure 2. 使用雙核心處理多工任務時，可以真實的在同一個時間裡執行兩個任務(Task)

分時多工為什麼不會拖慢任務的執行？

解釋完分時多工的原理之後，不知有沒有讀者產生一個疑問：「欸，分時執行多個任務好像也不能節省時間啊！如果一個任務要一分鐘才能處理完成，三個任務那就要三分鐘。雖然採用多工的方式可以同時雨露均沾，但是因為每一個任務變成一段時間才會被照顧一下，所以雖然三個任務同時進行，但最後卻每個任務都要三分鐘才能完成，好像更耗時了是不是？」

是的沒錯，這個邏輯確實正確，而對於那些計算量滿載的程式來說也確實就是這樣，實際上因為任務調度需要切換工作的關係(就是所謂的「上下文切換」(Context Switch))，總體需要的執行時間還會比一個工作全部一口氣執行完了再換下一個的做法還要更久。然而當下流行的這種多工手段之所以在實際應用上可以同時處理多個程式任務還不多消耗時間，根本的奇妙原因其實是因為大部份的程式的絕大部份時間裡都在閒著等待！什麼意思呢？比方以你的程式裡面要讀取檔案內容來說，讀取檔案這件事對 CPU 來說是屬於相當曠日費時的事情，當下達了讀取的命令之後要等到實際將資料送回來都是猴年馬月之後的事了(以 CPU 視角來看)，而這段時間 CPU 就只能空等著。類似這樣的程式操作還有很多，比如網路收送資料、等待週邊設備收送訊息等等，甚至對於大部份的圖形介面(GUI)程式來說，程式的執行週期裡其實花最多的時間是在等待你按下按鈕等操作輸入，而真正幹實事的時間比例實際上相當低。因此我們實際每天使用的大部份程式的任務工作裡其實包含了大量的等待，而在分時多工的任務調派結構下，作業系統就會在一個任務進入等待的時候立刻切換去執行別的任務。這就是為什麼我們可以同時開啟多個程式，甚至如果打開任務管理器的話可能還能見到上百個程式在背景默默的執行著，卻讓我們並不覺得程式會卡住變慢的原因了！ (不過你不要問我 Windows，我也不知道為什麼 Windows 有些時候放著啥事不幹也會卡頓，那是微軟的問題！)

然而以上是對於大部份的日常程式而言，但若對於那些計算集中類型的程式，比方跑模擬計算、影片與特效渲染、壓縮與解壓縮等等的這些程式來說，那麼情況就不一樣了！對於這種任務裡多是密集的計算工作的，而非日常程式含有大量等待的程式，它們確實就會發生向前面所提問的問題一樣的情況。當這種計算密集的任務數量小於等於 CPU 核心數量的時候，執行基本不受影響，因為多個 CPU 核心真實的可以同時執行這些任務；然而當計算密集的任務數量大於 CPU 核心數量的時候，延遲與卡頓情況就出現了。這時多工系統雖然也能看起來同時執行這些任務，但是總共需要完成的時間就更久了，甚至於會排擠到其它處理視窗、鍵盤等等這類工作的任務，從而導致使用者能夠體感到電腦的操作反應變得遲緩。

多工的背後

感覺上好像多工處理原理就是這麼的簡單，不過就是這邊做一做就放著，然後再到那邊做一做，就是把工作切成一小段一小段然後輪流執行。原理就是這樣簡單是沒錯的，然而實際上的多工排程其實是相當複雜的。怎麼說呢？假設我們的電腦同時有 100 條任務要進行好了，那麼每個任務應該要平均分配時間嗎？或者換個話說，每個任務是地位相等的嗎？有沒有一些任務可能比其它任務更加重要，使得我們希望作業系統儘量在比例上多分配一些時間片給它們？又或者有沒有哪一些任務可能相當具有即時性，使我們並不樂見它們在某些事情發生的時候還要排隊排好久才輪到執行？我們是否希望某些高時效性的任務能在需要的時候可以插隊搶佔？然而這樣又會產生出更多問題來，比方說如果我的電腦執行了不少被設為高重要性、高時效性的任務，那麼有沒有可能作業系統和 CPU 光處理那些任務就忙死了，完全沒空處理等級較低的任務？有些任務可能重要性真的很低，例如即時通訊軟體接收好友傳來的訊息，但是你覺得在你跑一些影片渲染、計算模型等工作的時候，朋友正在瘋狂敲你的訊息完全收不到是可以接受的嗎？意思就是在滿是高優先級任務滿載的情況之下，是否其它那些即便是最不重要的任務，任務排程也應該偶爾照顧到它？或者是也許用戶覺得高優先級的任務最重要，讓低優先級的餓死也沒關係(作者我還真處理過這樣設計的系統)？或甚至於，作業系統分配的時間片(Timeslice)應該是等長的嗎？

提出以上這些問題並不是真的要我們去做解答，因為實際上這些問題的解答都是好幾本論文的份量了！將這些問題提問出來，只是想讓我們知道原來在簡單原理的背後還有這麼多的門道。而在作業系統內去完成這些任務分配與調度的工作，就叫作任務「排程」(Scheduling)。排程的各種算法和取捨也是一個相當有挑戰性的工作，事實上對於那些世界上頂尖的超級電腦，往往開發設計團隊還會針對它們的需求去調整優化自己的任務排程器的設計；好在對於我們站在應用程式的視角來說，不需要去實際處理這些問題，只需要知道原來我們的執行緒(就是本文裡的任務(Task))在作業系統背後經歷了這些事情，然後知道我們的執行緒無論如何會在合理的時間裡被作業系統喚醒執行就可以了！

最後再來補充一些關於時間片與任務切換的時機。原則上作業系統排程器會在適當的時候給予任務一段執行工作的時間，也就是前面解釋過的時間片，正常來說當這個時間終止以後，排程器就會把任務暫停，然後切換去執行其它的任務。然而其實在許多實際的情況下這個時間片可能是用不完的，也就是時間片的時間還沒到，任務就會被切走了。什麼時候會發生這種事呢？除了可能被那些重要性比你更高的任務插隊，或者被硬體或軟體的「中斷」(Interrupt)機制打斷之外，其實很多時候是任務自己主動放棄的！比方說當我們的程式讀取檔案內容的時候、呼叫網路收送的時候、呼叫系統安排調度資源的時候等等，那些操作的後面就是要進入等待，等到該等的東西來了以後才能夠繼續往下執行。因此這時候即便時間片的時間還沒有用完，我們的任務也會立刻被作業系統給岔出去 (然後直到等到了我們的程式需要的東西之前都不會回來了)。

總結

本篇解釋了現代分時多工的原理，了解了電腦系統如何讓我們的電腦可以同步執行成千上萬個程式與執行緒的方式，其實就是在各個工作之間不斷來回切換，這邊做一小段再去那邊做一小段。並且本篇也在解釋敘述的過程中介紹了許多與執行緒和排程相關的專有名詞，了解這些名詞與意義將有助於在讀者自行搜索相關資料的時候更容易理解。本篇的原理解釋也是本系列文章裡相當重要的一部份，將是系列後續其它文章的背景知識基礎。

執行緒同步 1：簡介

Sat, 24 Jan 2026 01:24:08 +0800

這個系列要來介紹各種執行緒同步的方法工具，包含各種的鎖等等。而本篇首先讓我們先來初步認識什麼是執行緒，並簡單的嘗試自己建立執行緒的方法。

雖然說本篇主打的是一個新手教學，但也並不是針對完完全全的新手。這裡期望的讀者可以不知道或沒有接觸過執行緒，可以是執行緒的新手，但是不能夠是程式設計的新手！本系列將假定讀者對於一般通俗的 C/C++ 程式設計已經擁有一定程度的熟練掌握，並且在此基礎之上針對執行緒的知識進行介紹與講解。所以如果甚至還沒學會基本的程式設計的話，那麼閱讀本系列將可能會有些吃力！

什麼時候需要多執行緒？

什麼是執行緒？一個執行緒其實就是一個程式的執行流程。

我們一般入門程式設計時的書籍和課程都不會觸及到執行緒這個東西 (畢竟先把程式基礎的邏輯和用法學起來就已經份量相當足夠了)，也可以說我們一般入門學的程式都是只有單一執行緒的結構，也就是只有程式一執行起來時系統就給了的那一個執行緒而已。單一執行緒就是我們的程式只有一個執行流程，依照程式碼的順序從頭執行到尾，也許中間有些跳轉情況如分歧、迴圈、函式呼叫等，但終究還是只有一個執行流。那麼什麼是多執行緒呢？多執行緒就是程式中存在多個同時、平行、同步在進行的執行流程。

舉個例子，用我們生活中一般使用電腦的經驗來類比的話，那麼當我們開啟網路瀏覽器在上網看網頁的同時，後面又有一個音樂播放器正在播放音樂，旁邊還有一個網路聊天程式隨時會顯示好友傳送的訊息。那麼這時我們其實就是在進行所謂的多工作業，三隻程式個別都有(至少)一個程式執行流正在進行，並且是同時都在進行的，才讓我們可以在看網頁的同時一邊和朋友聊天、聽音樂。這其實就是一種多緒(執行緒)的應用場景；或者也可以這麼說，雖然我們自己也許可能從來沒有認知到這件事，但是只要我們有使用電腦同時執行多個程式的經驗的話，那麼我們其實都已經使用過多執行緒技術了！

回到我們自己寫的程式碼這裡，只有一個執行流的程式往往使我們不得不停下來等待某些需要耗時的工作完成。例如若我做一個在按下按鈕時會從 A 處複製一大堆檔案到 B 處的程式，那麼當按鈕按下去的時候程式就會卡住在那裡……，好吧其實它很認真的在工作，正在努力的不斷複製檔案，但是整個程式的操作介面就這麼卡住了，直到工作完成前顯然沒辦法再響應其它的按鍵、滑鼠等操作。然後使用者可能就會因為覺得程式當掉了而直接把程式終止！這時我們就可以將程式改為建立一個單獨的執行流，即一個新的執行緒，然後在那個執行緒裡面去處理檔案複製的工作。而本來的執行緒就可以繼續進行其它工作，例如繼續響應使用者的操作、三不五時檢查另一個執行緒的工作狀態並顯示完成進度等等。

依此類推，我們還可以建立多條執行緒去分別處理各種比較耗時的工作，讓它們可以同時同步進行，而不需要一個等一個，而這就是學習並建立執行緒的一種常見用途。此外還有更多其它用途，例如將一個相當複雜又耗時的運算分割成幾個部份，然後分派給幾個執行緒同步進行計算。這就是所謂的「平行處理」，充份利用多個 CPU 核心的性能來分攤計算量，縮短總體的計算時間。 (其實使用顯示卡 GPU 或近年流行起來的 NPU 來進行運算都是相似的平行運算原理。) 總之，學習並善用多緒的能力可以給我們的程式帶來更多的設計彈性和性能提升空間。當然，多緒也會給我們帶來更多憶想不到的複雜性增加，以及各種問題和挑戰，而這也是為什麼光一個執行緒同步的主題可以變成一個文章系列的原因！

範例

假設我們有一個函式在執行的時候需要花費許多時間 (在更真實的應用中有時候除非你叫它停，否則它永遠不會停)，那麼我們可能就會想要把這樣的函式放在一個獨立的執行緒裡面去執行，讓我們原本的程式碼可以繼續去做其它的事情，不用等待函式結束。那麼這裡作為範例，就假設有一個像下面這樣的函式：

static int global_variable_0 = 0;
static int global_variable_1 = 0;
static int global_variable_2 = 0;
static int global_variable_3 = 0;

static
int ThrdFunc3(void *arg)
{
    for(int i = 0; i < 7; ++i)
    {
        global_variable_3++;
        printf("In function 3: variables = %d, %d, %d, %d\n",
            global_variable_0, global_variable_1, global_variable_2, global_variable_3);
        SleepMs(700);
    }

    return 0;
}

這個函式看上去就是一個普通的 C 函式，它可以接收一個 void* 型態的參數，並且會返回 int 型態的回傳值。正常來說所有進出函式的資料都應該透過那個 arg 參數給傳遞進去，使用全域變數是個壞習慣，但在這個範例裡面主要是為了能夠更加直觀的表達不同執行緒可以存取共同記憶體空間的緣故，因此還是使用了全域變數的寫法；但是這是相當特殊情況的寫法，請小白們不要亂學，平常還是不要隨便寫全域變數的好！

對於這樣一個函式，一般來說如果我們要去呼叫它的話，會像下面這樣寫：

int res = ThrdFunc3(NULL);

啟動執行緒

就像前面說的，上面那函式的執行會花上不少時間，而我們呼叫的地方又不希望卡住停在那裡等它。那麼這裡我們就來建立另外一條執行緒，然後把這個函式放在那個獨立的執行緒裡與我們平行執行，做法如下：

thrd_t thr; // Handler of the new created thread
int err = thrd_create(&thr, ThrdFunc3, NULL);
assert( err == 0 );

這裡呼叫了 thrd_create() 函式，並讓 thrd_create() 代替我們去呼叫 ThrdFunc3() 函式。為什麼要這樣間接呼叫呢？因為 thrd_create() 會建立一條新的執行緒，然後用那條新的執行緒去執行 ThrdFunc3()。因此這個 thrd_create() 完成它的任務之後就會直接返回了，而它返回的時候那個 ThrdFunc3() 函式可能還正在努力的執行中呢！

但是這裡還有一個問題，前面我們的 ThrdFunc3() 不是需要傳入一個參數嗎？那現在這個參數要怎麼傳給它呢？雖然我們現在的這個範例並沒有實際使用到這個參數，但是在實際用途中總不能夠沒辦法傳遞參數給我們要間接執行的那個函式吧？其實 thrd_create() 的第三個參數就是為此而設計的。我們能將任何能轉型成 void* 型態的參數填入 thrd_create() 的第三個參數，然後 thrd_create() 就會幫我們轉交給我們要它代為執行的那個 ThrdFunc3()。完整的 thrd_create() 函式介面如下：

typedef int(*thrd_start_t)(void *arg);

int thrd_create(thrd_t *thr, thrd_start_t func, void *arg);

其中有兩點事情需要注意：

func() 在執行緒被建立之後可能很快就會被執行，甚至可能在 thrd_create() 返回之前就已經開始執行了。因此所有新的執行緒函式需要取用到的相關資源都需要在呼叫 thrd_create() 就已處於可用狀態。
func() 也有可能在 thrd_create() 返回之前就已經執行結束了。比方說傳入的函式內容相當短小精練以至於一下子就執行結束了，或者是系統自己卡了一下等等，都是可能造成這個現象的原因。無論如何，使用者都需要意識到這個現象的可能存在，除非設計有彼此互相確保協同的機制，否則寫作的程式不應假定 func() 必定還在執行中狀態而還未結束。

關閉執行緒

也許你注意到了，呼叫了 thrd_create() 之後它會給我們一個 thrd_t 型態的物件，這東西也是有作用的。它就是一個指向新建立的執行緒的操作器(handler)，我們可以使用它來對那條執行緒進行許多操作，比方比較執行緒、調整執行緒屬性、暫停與恢復執行緒等等(不過 C11 的 API 好像沒有覆蓋這麼多功能)；然而其中有一項功能是我們最常使用且必須使用的，那就是關閉執行緒操作器！就如同開了檔案後要記得關檔，或者分配了記憶體後要記得釋放一樣，啟動執行緒並得到操作器之後也要記得關閉它，否則也同樣可能會產生資源洩漏的情況。不過這裡要注意一個區別， 所謂關閉操作器僅僅只是關閉掉那個 thrd_t 物件而已，它本身並不會結束執行緒，而執行緒本身的結束與否在於我們丟給執行緒的那個函式什麼時候自己返回退出。

要關閉執行緒操作器，可以選擇呼叫下面兩個函式的其中一個：

int thrd_join(thrd_t thr, int *res);
int thrd_detach(thrd_t thr);

上面兩個函式都能關閉執行緒操作器，區別在於 thrd_detach() 只是單純的關閉而已，關了之後就不管了，那個執行緒可能仍在執行中，或者早就已經結束掉，都無所謂，thrd_detach() 都會直接返回。而 thrd_join() 不一樣，它會等待直到那條執行緒結束之後才會返回；當然如果那條執行緒早就已經結束了的話那就會直接返回。此外還有一個差別，因為 thrd_join() 會等待執行緒結束，因此可以順便轉交給你你的執行緒函式的返回值，那個 res 參數就是用來接收返回值的；而 thrd_detach() 因為返回的時候執行緒可能都還沒結束，自然就無法回給你這東西了。

因為這兩個函式只負責關閉執行緒操作器而已，而與該執行緒本身的運作無關，因此在你呼叫這兩函式之前，執行緒有可能早就已經自己結束了千八百年了，比方你經過很久才呼叫關閉操作器，或者你的執行緒函式本身就短小精幹等。這一點在設計的時候也需要注意，以免得發生一不小心去存取了早就在你的執行緒函式裡面銷毀了的資源！也因為同樣的關係，如果你的設計上並不需要留著操作器進行一些進階的操作的話，甚至也可以在剛呼叫了 thrd_create() 建立完執行緒之後，立刻就呼叫 thrd_detach() 關閉操作器，然後就繼續做你的事情，就放著新的執行緒在背後該幹什麼就幹什麼。

Note	在我寫作執行緒同步系列文章搜尋資料的時候才發現，有些妖術會教你用 cancel thread 之類的 API 去停止執行緒，這是不對的，請不要學！那些 API 確實可以把執行緒停下來，但那其實是非正常強制終止執行緒的手段。若總是使用它來讓你的執行緒停下來，那就好像是每次都使用系統的行程管理器去強制殺停你的程式一樣，能用是能用，但是不正規，不是正常關閉，有時候會產生一些後遺症。同樣的，當你把強制停止執行緒的方法當作正常停止的方法來使用，那麼程式因此發生什麼奇奇怪怪的異常問題也都是很正常的事情了！正規的途徑還是要使用旗標狀態檢查等手段，讓執行緒函式自己正常自然的退出並結束。

範例

解釋完如何建立和關閉執行緒之後，這裡提供一個範例。這個範例內手動建立了 3 個執行緒，加上一個程式本來就有的執行緒，總共執行緒有 4 個。每一個執行緒都執行了一段與上面展示的 ThrdFunc3() 一樣的程式碼，只不過各自的顯示訊息、迴圈等待的時長、和覆寫的變數等等稍有差異。這個範例執行後的結果輸出如下：

In function 1: variables = 0, 1, 0, 0
In function main: variables = 1, 1, 0, 0
In function 3: variables = 1, 1, 0, 1
In function 2: variables = 1, 1, 1, 1
In function 1: variables = 1, 2, 1, 1
In function 2: variables = 1, 2, 2, 1
In function 1: variables = 1, 3, 2, 1
In function 3: variables = 1, 3, 2, 2
In function 1: variables = 1, 4, 2, 2
In function main: variables = 2, 4, 2, 2
In function 2: variables = 2, 4, 3, 2
In function 1: variables = 2, 5, 3, 2
In function 3: variables = 2, 5, 3, 3
In function 2: variables = 2, 5, 4, 3
In function 1: variables = 2, 6, 4, 3
In function 1: variables = 2, 7, 4, 3
In function main: variables = 3, 7, 4, 3
In function 2: variables = 3, 7, 5, 3
In function 3: variables = 3, 7, 5, 4
In function 1: variables = 3, 8, 5, 4
In function 1: variables = 3, 9, 5, 4
In function 2: variables = 3, 9, 6, 4
In function 1: variables = 3, 10, 6, 4
In function 3: variables = 3, 10, 6, 5
In function main: variables = 4, 10, 6, 5
In function 2: variables = 4, 10, 7, 5
In function 1: variables = 4, 11, 7, 5
In function 1: variables = 4, 12, 7, 5
In function 3: variables = 4, 12, 7, 6
In function 2: variables = 4, 12, 8, 6
In function 1: variables = 4, 13, 8, 6
In function 1: variables = 4, 14, 8, 6
In function main: variables = 5, 14, 8, 6
In function 2: variables = 5, 14, 9, 6
In function 3: variables = 5, 14, 9, 7
In function 1: variables = 5, 15, 9, 7
In function 2: variables = 5, 15, 10, 7
In function 1: variables = 5, 16, 10, 7
In function 1: variables = 5, 17, 10, 7

從交叉輸出的訊息，我們能夠確定四個函式(三個建立的執行緒加主程式原有的一個)確實是同時在進行的。而從它們輸出的變數狀態都不斷在變化的情況，也能確認在不同的執行緒之間確實能夠共享程式資源 (在這個範例裡展現的就是可以共同存取程式內的變數)。

關於系列文章的規劃藍圖

文章至此，讀者應該已經俱備了能夠創建多執行緒的基本能力，可以開始實現多緒的程式設計了。不過執行緒的各種眉角和陷阱還可多著，否則又怎麼會讓人人都說多緒編程難呢！其實有經驗的讀者可能已經發現了，本篇的範例相當雞賊的繞過了多緒競爭的問題，畢竟只是一個剛開始的範例，還沒必要搞到那麼複雜；至於其中更多的問題與對策，就留待後續的文章慢慢介紹了。

然而與執行緒有關的議題實在太多太大，作者我的個人能力實在沒能夠全盤交代清楚，因此本系列文章的絕大部份內容將專注於執行緒同步方面的問題，介紹與解釋各種對策方案及其原理。

最後則是交代一下關於執行緒 API 的選用部份。關於執行緒，各作業系統都有自己的執行緒相關 API。例如以建立新執行緒來說，就有 POSIX 相容系統(如 BSD、Linux、和 UNIX 等)的 pthread_create()、和 Windows API 的 CreateThread() 等，以及 2011 年以後的 C++11 的 std::thread、和 C11 的 thrd_create()，此外可能還有更多比較小眾的 API 與函式庫等等。執行緒的 API 與函式庫有好多種不同的介面與實現，每一種方案各有些細節和特性上的不同，實在很難每一個都清楚解釋；然而它們雖然各自不同，在用法結構上卻大同小異。因此本系列文章將避免過於深入各種實現細節，而只針對原理和框架等層面去做說明解釋，畢竟大部份情況下我們缺少的更可能是對整體、原理、特性、和適合用途的通盤理解，至於操作細節只要去查閱各 API 的相關說明文件就能知道了！

不過文章的說明解釋是一回事，但程式碼範例總是要能夠編譯執行的。這程式碼的部份，可能會相當多的採用 C++ 寫作，畢竟 C++ 的封裝用起來還是比純 C 更加方便簡潔；然而在所需要解說的執行緒相關操作上則會使用 C 語法與呼叫，因為 C 語言雖然可能瑣碎點但更加簡單直觀，更適合作為學習範例使用。因此在執行緒的 API 選用部份，我會以 C11 標準的執行緒程式庫為主，當遇到標準 C11 覆蓋不夠全面的相關功能時則會使用 pthread 程式庫，至於當遇到前兩者都不俱備的功能時才會使用更加冷門少見的 API；至於那些與主要訴求無關的其它程式碼，則可能會相當的採用 C++ 語法與工具。

螺旋槳 11：戰鬥機為什麼堅持單發動機？

Mon, 12 Jan 2026 00:22:56 +0800

不知道有沒有人好奇這麼一個問題：在螺旋槳大行其道的時代，那些戰鬥機為什麼(幾乎)都只使用一副螺旋槳？不同於現代的噴射戰鬥機，有些採用單發動機，有些採用雙發動機，甚至還有三發動機的；然而我們所熟悉的那些舊時代裡的螺旋槳戰鬥機，卻總是堅持單發動機和單螺旋槳的配置，這是為什麼呢？本篇就要來解答這樣的問題！

對於幾乎任何實用的飛機而言，總是能在方方面面找到它對動力渴求的願望。推力更大的動力系統往往表示能夠給飛機帶來更大的極速、更高的升限，或者能夠載起更多更重的貨物，或者能夠帶來更好的加速性能，而這些需求對於戰鬥機來說更是尤為重要，更強勁的推進裝置總是戰鬥機強悍機動性能的中央支柱。當然動力裝置本身也同樣在發展推進，可是往往動力的提升速度趕不上飛機的需求，這該怎麼辦呢？對於這個問題，一般來說解決的思路那是相當簡單又直接：「一個不夠，我就上倆」；倆還不夠，那就繼續加到三、四。于是乎那些中、大型的飛機往往就承載了複數的發動機，甚至有些型號裝到了八臺、十臺之譜，但是怎麼到了戰鬥機就不能這麼做了呢？其實說戰鬥機有一些籠統了，因為現代噴氣戰鬥機採用雙發動機的也已經滿坑滿谷了，甚至現在還有三發動機的型號問世，所以真正奇異的現象其實只出現在以螺旋槳為動力的戰鬥機身上！

回顧在那螺旋槳仍然主宰著航空界的一戰、二戰時期，各式有名的或無名的戰鬥機基本都只有一副螺旋槳，人們也總是在一臺發動機上面死磕，嘗試各種努力去壓榨單臺發動機的最大功率，但是怎麼就好像沒有人想到可以裝上兩具發動機來簡單的大幅提升動力呢？其實採用雙發動機的嘗試也並不是沒有出現過，比如赫赫有名的 P-38 閃電戰鬥機就是採用雙發動機、雙螺旋槳的戰鬥機，至少在太平洋戰爭初期也是少數能和零式戰鬥機扳手腕的對手。雖然確實存在，然而現實上採用雙發動機的螺旋槳戰鬥機是真的罕見，且大多數這樣的嘗試得到的結果是一架纏鬥性能羸弱的飛機。也因此在一般相關的介紹裡面通常都簡單的以「雙發戰鬥機之機動性能不佳，無法與單發戰鬥機對抗」簡單帶過，但對於雙發戰鬥機為什麼導致性能不佳的原因則大多未做深入解釋。於是本篇就來解釋一番為什麼雙發動機導致性能劣化的原因，同時也來看看人們在這個問題上摸索嘗試的努力巧思。

雙發動機的性能優劣

其實「性能」一詞涵蓋的範圍那是相當廣泛，採用雙發動機的方案在某些方面其實會比單發動機更具優勢，這也是為什麼雖然戰鬥機是單發動機的主流市場，但總是會有人想要動腦筋造雙發戰鬥機的主要原因。

那麼相比於單發動機，採用雙發動機存在哪些優勢呢？採用雙發動機能得到雙倍的推力，理論上有機會得到更大的極速 (然而雙發佈局往往機體更龐大、阻力更大，實際上速度不一定更快，只能說具有這方面的潛力)；或者即便在極速上未必具有優勢，但憑著更大的推力也能得到更強勁的加速性能，這些在戰鬥用途上都是優勢。推力更大，也就能夠承載更多的武器和各種設備，攻擊威力更大，長距離導航能力更佳；更大的酬載力也使得能夠帶上更大量的燃油，使能得到更遠得多的航程，而這也是二戰時期那些試圖研發雙發戰鬥機的國家往往都是需要長程護航轟炸機的進攻方的原因！

以上是雙發動機的優勢，那麼劣勢在哪裡呢？雙發動機的劣勢在於發動機的重量。不過這麼說也不精準，因為兩倍的發動機重量在得到的雙倍推力之下反而是個相當不錯的投資回報。因此更準確的來說其實是因為發動機的重量所導致的轉動慣量大幅增加，以致於削弱了轉向方面的性能，也就是改變飛機姿態的反應速度。

Figure 1. 作用在飛機上的基礎四個力 ^[1]

Figure 2. 飛機旋轉三軸：左為俯仰(Pitch)，中為滾轉(Roll)，右為偏航(Yaw) ^[2]

在三維空間運動的飛機同樣存在三個軸向的移動和旋轉，比如航空基礎知識裡面的飛機四大力所描述的就是兩個方向的力消長關係，如(巡航平飛狀態下的)推力和阻力描述的就是飛機前進方向上的力平衡關係，而升力和重力描述的就是飛機垂直向的力平衡關係(如圖 Figure 1)。 (至於最後一個軸向的作用力即飛機側向的受力和平移，因為通常情況下其佔比相當低， 一般用偏航姿態調控的手段就把它處理掉了，以致於不會出現在通俗的討論中。) 除平移方向之外，飛機在三個軸向的旋轉則對應飛機的三個軸向姿態控制，即偏航、俯仰、和滾轉(如圖 Figure 2)。在上述的兩軸平移和三軸旋轉中，有賴大推力的優勢，雙發動機的配置在平移方向上的性能表現總是優於單發動機，而因為轉動慣量增加所導致的劣勢主要是存在於軸向旋轉即姿態控制的表現上，下面我們會一個一個來做圖解。

飛機三軸姿態

發動機的重量對飛機來說佔比相當大，特別是在小飛機上更是具有舉足輕重的地位，其中發動機距離轉軸(也就是飛機的重心位置)距離愈遠會導致繞軸旋轉的慣性愈大，發動機愈靠近軸心(重心)的話則飛機在這個軸向上的旋轉慣係愈小，轉向就會更容易且迅速。雖然螺旋槳和發動機的配置有各種變化 ^[3]，但我們先不要一次弄的那麼複雜，下面我們先就最常見的單槳前拉，和翼掛雙槳佈局來作對比，在最常見流行的配置下比較單雙槳的性能表現。

Figure 3. 單、雙發戰鬥機轉動慣量對比之：偏航 ^[4] ^[5]

飛機在如上圖(Figure 3)所示的姿態旋轉被稱為「偏航」(Yaw)。在這個方面，單發動機配置的發動機距離飛機重心的位置明顯比雙發動機配置的情況更短得多，因此在偏航操作上，單發動機的操作響應速度更快，而雙發動機的反應速度則佔劣。不過因為偏航在飛機的各種機動動作中往往只佔輔助和微調的角色，而非主導性的地位，因此雖然雙發動機配置確實在這上面吃點虧，但實際影響並不大。

Figure 4. 單、雙發戰鬥機轉動慣量對比之：俯仰 ^[4] ^[5]

如上圖(Figure 4)所示的姿態旋轉則被稱為「俯仰」(Pitch)。兩種發動機配置在這方面不分軒輊，也就是說單、雙發動機的配置對俯仰操作的響應速度並沒有明顯的差距。因此兩者在爬升和下降等機動動作上並沒有操作反應上的差距，甚至於因為推力更大的關係，雙發動機戰鬥機反而在爬升性能更加佔據優勢 (至於俯衝是否仍具優勢則還要看機體的阻力表現)。而在(同一個方向的)水平迴旋上的性能表現，兩種配置的反應也同樣不分軒輊，甚至同樣因為動力更加強勁的原因，雙發戰鬥機更加具有優勢(或潛力)。

Figure 5. 單、雙發戰鬥機轉動慣量對比之：滾轉 ^[4] ^[5]

如上圖(Figure 5)所示的姿態旋轉稱為「滾轉」(Roll)。可明顯看出兩種發動機配置在這方面的表現差異相當巨大，其兩者之差距更甚於在偏航上的表現。然而雪上加霜的是，與偏航在機動動作之中的輔助地位不同，滾轉對於機動性能具有關鍵的影響力。而現實上同樣如此，滾轉性能其實才是雙發戰鬥機的最大劣勢之所在。

更進一步說明滾轉如何影響戰鬥機的機動性能？如果是對於航空沒有基礎知識和經驗的新手經常會直覺的覺得飛機是靠「偏航」來轉彎，然而實際上飛機的迴轉卻是滾轉加上俯仰同時協同操作所帶來的結果(如圖 Figure 6 和 Figure 7 所示)。為什麼是這樣呢？可能與一般常聽聞的理由並不相同，「乘員舒適性感受」僅佔了最不重要的因素。畢竟在生死戰場上，為了壓榨出飛機的極限性能，往往更傾向於讓飛行員去承受各種「不舒服」的體感。其實飛機通常都採用滾轉加俯仰來實現轉彎的原因只有一個：極限的轉彎需要強大的向心力作為支持，而飛機上的大翼就是唯一一組可以提供最大作用力的翼面；因此原理在於使用大翼的升力來作為轉向所需之向心力的提供者， 而滾轉操作的角色也僅僅只是改變大翼升力的方向使其能作用於轉向所需的方向。 當然也不是說不能採用一般人直覺的偏航手段來轉向，只不過實際使用方向舵偏航來轉彎的話會發現一件事，感受舒服不舒服倒在其次，主要是轉彎率可能會相當之低！

Figure 6. 飛機的轉向其實是滾轉加俯仰的協同操作 ^[6]

Figure 7. 飛機使用滾轉的方式，將主翼所產生的升力分出一部份來作為轉向所需的向心力使用 ^[2]

上面說明了飛機迴轉的原理，但只是這樣的說明可能還是難以明白的解釋為什麼雙發戰鬥機會在迴轉操作上吃虧的原因；甚至於從前面解釋的整個原理來看，雙發戰鬥機憑著俯仰操作的平起平坐再加上動力上的優勢，不是理論上應該轉彎更加能轉贏單發戰鬥機嘛？那麼問題出在哪裡呢？問題的核心就在「反應速度」這方面上！我們現在知道飛機的迴轉是滾轉與俯仰共同操作的結果，那麼在像是正在向左急轉狀態的戰鬥機突然要切換成向右急轉的時候，雙發動機滾轉速率低的劣勢即在此展露無遺，其滾轉速率慢的特性將導致轉向反應遲緩。並且在空中纏鬥的情況下，誰也說不準下一秒另外一架飛機想要做個什麼姿態？在這組合無限且千變萬化的空戰戰場上，雙方時刻都處在姿態快速變化的情境，除了比拼飛機的硬性能之外也同樣比較讓對方措手不及的反應速度，因此才讓雙發戰鬥機滾轉反應慢的這特點拖了個大後腿！即便在只朝一個方向轉彎的表現上雙發動機不見得會輸，但敗就敗在了不斷左騰右挪上竄下跳的反應速度上，總結一句話就是雙發戰鬥機不如單發戰鬥機「靈巧」。

整理前面的所有內容，可以得到這麼樣一個結論：雙發動機在各方各面對於單發動機都有碾壓性的優勢，部份稍嫌劣勢的地方大多無足輕重，惟獨僅僅只在滾轉這個項目上吃虧而已；然而卻如此不巧，滾轉對於戰鬥的機動性能影響力佔據了核心的關鍵地位，使得雖然雙發動機只輸了這一項，卻就是因為這個項目導致全盤輸掉空中戰鬥的優勢！

雙發戰鬥機案例分析

前面解釋了為什麼雙發戰鬥機在機動性能上不如單發戰鬥機靈巧的原因，而那就是為什麼螺旋槳時代的戰鬥機總是堅持使用單一發動機，並且總是想盡辦法圍繞著一臺發動機壓榨動力的原因。甚至於到了二戰後期，明明後推式螺旋槳存在這樣又那樣的問題 ^[7]，但還是不乏有人在那上面去做嘗試，其實那說白了也就是在單一發動機的功率潛力已經逐漸枯竭 ^[8] 的情況下，改從動力佈局的方式來榨出性能提升空間的嘗試。甚至於還有人從函道螺旋槳的方向來試圖提升推進的效率 ^[9]，雖然最後的結果失敗了，但這些種種的嘗試其實都在訴說著，人們圍繞著功率已經逐漸達到天花板的單一發動機上面死磕的現象。

Figure 8. 採用後推式佈局的震電戰鬥機 ^[10]

Figure 9. 採用後推式佈局的 XP-55 戰鬥機 ^[11]

Figure 10. 採用函道螺旋槳的義大利 Stipa-Caproni ^[12]

在堅持單一發動機而不斷絞盡腦汁的情況下，當然就不乏在任何時候都會有人不死心想給戰鬥機安上兩臺發動機的想法，那麼下面就讓我們來回顧這些歷史上曾經出現過的雙發戰鬥機。只不過就如同前面所說，大部份雙發戰鬥機都會面臨程度不等的敏捷性降低的結果，因此如何儘可能的減少敏捷性的劣化就成了雙發戰鬥機設計上的重中之重。

Bf 110

Figure 11. 採用雙發動機翼掛佈局的 Bf 110 戰鬥機 ^[5]

Figure 12. 採用雙發動機翼掛佈局的 Bf 110 戰鬥機 ^[5]

想到雙發戰鬥機，最簡單的作法就是比照通常雙發動機飛機的佈置，將兩個發動機和螺旋槳掛機翼上。這種設計方案曾經出現在不只一款飛機上，但本文只以 Bf 110 作為代表性案例。

作為所有雙發戰鬥機裡面最不經「巧思」的配置，Bf 110 的空戰機動性能相當令人捉急，在空戰中但凡遭遇任何當年比較正經的單發戰鬥機對手那都相當吃虧。在真實的歷史上，Bf 110 雙發動機的設計使它具有足夠的航程能夠跟隨轟炸機一起跨越英吉利海峽，然而在面對英國戰鬥機的時候卻沒能發揮多少護航的作用，甚至經常淪為需要被護航的對象！不過這裡並無意抓著 Bf 110 的弱點大肆批鬥，其更大的意義是作為一個最典型佈局的比較對照組。

P-38

Figure 13. 同樣採用左右雙發動機，但嘗試使用更緊湊堅固框架式結構的 P-38 戰鬥機 ^[13]

有鑑於板板正正的雙發動機佈局帶來的機動性能劣化問題，P-38 閃電式戰鬥機嘗試了另一種解題方案，造成了相當具有辨識性的獨特外觀。閃電戰鬥機捨棄了常見的單一機身，將左右兩具發動機分別安裝在兩側的兩個相較更纖細的機身上，以主機翼和水平尾翼一前一後相互連結，成為一個大的矩型框架，然後將其餘的人員與武器等塞入小得多的中央吊艙；或者也可以理解為將機身縮小至只剩中間那一小塊，至於兩側則是延伸的尾桁結構，意思是一樣的！

作為一個雙發戰鬥機，P-38 的航程和動力肯定是相當具有優勢的，其飛行極速在同時期的戰鬥機裡面也屬於佼佼者。甚至其因為武器系統都置於機身中央的緣故，還少掉了當時主流戰鬥機機槍安裝於兩側機翼上時會產生的火力匯聚與分散問題，不過這與本篇專注的動力系統無關，就不多進行深入探討。關注其空戰機動性的部份，整體機體構成的大矩型結構給予它相當大的結構強固性，除了更能夠扛傷害之外，也更承受得起更激烈的姿態操控力道，因此 P-38 的機動性放在雙發戰鬥機的範圍裡面那可算是相當靈活的。但是那畢竟是放在同為雙發的範圍內，而當與主流的單發戰鬥機作對手時， P-38 依然顯得敏捷性不足，空戰機動能力對上大部份當時的單發戰鬥機仍是處於弱勢下風。在歷史上，雖然 P-38 纏鬥靈敏性不及對手，但是憑藉著雙發動機帶來的大馬力和飛行速度，依靠俯衝、爬升等基於垂直面的運動戰鬥，在以中低空作戰為主的太平洋戰場上取得相當不錯的成績。然而在另一邊高空作戰為主的歐洲戰場，垂直機動作戰一般較難施展 (畢竟已經飛很高了，還要再飛更高來俯衝就更不容易)，加上對手的單發戰鬥機馬力和速度本就不俗，因此成績並不理想，很快就退出了空戰第一線。

Do 335

Figure 14. 將兩具發動機佈置在機身前後，採用一前一後兩副螺旋槳共同作為動力的 Do 335 戰鬥機 ^[14]

Figure 15. 從前方角度觀看 Do 335 戰鬥機 ^[14]

在雙發戰鬥機的構思上，Do 335 箭式戰鬥機應該算得上是螺旋槳時代的登峰造極之作了！將兩具發動機同螺旋槳分別佈置在機頭和機尾，形成前拉加後推的雙螺旋槳佈局，兩具發動機一前一後全都位在機體中軸線之上，使得滾轉方面的轉動慣量堪比單發動機的戰鬥機。這種佈置在得到雙發動機的大推力、高速、與航程等優勢之外，還保留了對戰鬥機來說極度重要的滾轉速率。雖然在俯仰方向的轉動慣量增加而導致俯仰反應速度會有所遲緩，然而因為其重要性佔比與滾轉相比低得多的緣故，對空戰機動性能的劣化程度表現確實存在但並不顯著；至於偏航方向的轉動慣量造成的偏航速率些微下降，也是確實存在但更加不影響總體性能了。

這種螺旋槳佈置方式使得 Do 335 在空戰機動性能上能夠具有與主流單發戰鬥機互搏一番的實力，俯仰速率稍有遲緩但還處在能被其它優勢追平的範圍內，而滾轉速率則是與單發戰鬥機不相上下。並且在此前提下，Do 335 同時還具有雙發戰鬥機才有的馬力和速度優勢，使得綜合空戰能力足以壓倒同時代大部份單發戰鬥機，實為一種相當優秀傑出的重型戰鬥機設計。只不過可惜了 Do 335 出現的時候已經是二戰晚期的 1944 年，加上產量極為稀少，並沒能留下能讓軍武愛好者傳誦的功勳事蹟；再往後就成了噴射戰鬥機馳騁天空的舞臺，也沒有人再有餘裕去搗鼓螺旋槳戰鬥機了！

不過既然方案這麼簡單(至少看似如此)，僅僅只是把螺旋槳一前一後擺放而已就能夠兩邊好處都佔，那為什麼這種設計直到二次大戰晚期才出現呢？這主要因為兩個原因所導致。其中第一項原因就是沒人想到並著手實現。可別太感到意外，歷史上已經有太多這種被推出之後突然技驚四座讓人拍案，但公開亮像之後卻同時讓眾人感到扼腕，喊叫著「原來還能這樣搞，我咋沒早點想到」的東西了！比方迴紋針、比方拉瓦爾噴管，都是技術上並無太多實現難度，原理說出來了大家也都早已理解，但在第一個人用出來之前就是沒人想到的東西。因此在 Do 335 之前沒有人想到(或者想到但不敢去實現也歸在內)能夠這樣建造雙發戰鬥機，實在也是很合理會發生的事情。

第二項原因就是實際的技術困難了，可能也是也許有些歷史裡的人物可能天馬行空時想到過但卻沒有實際去付諸實行的阻礙。有關於後置螺旋槳的各種缺點與困難在從前的文章已經分析過 ^[7]，因此要打造前後推拉式動力系統的飛機同樣也會遇上那些困難，何況一前一後兩個發動機與螺旋槳的系統，除了本身因為零件數量翻倍而造成的複雜度之外，還會因為其之互相干擾影響而把整體效應弄得更加複雜。可能也就是因為如此，才讓直到 Do 335 之前的許多戰鬥機設計者，最後仍採用保守傳統的左右對稱翼掛發動機佈局的原因吧！

夜間戰鬥機

Figure 16. 專為夜戰打造的 P-61 黑寡婦戰鬥機，採用與 P-38 相似的雙發動機佈局，搭載了先進的雷達系統 ^[15]

Figure 17. 將原本機動性能令人捉急的戰鬥機加裝雷達系統後搖身一變成為 Bf 110G 夜間戰鬥機，機頭碩大的雷達天線明顯可見 ^[5]

二戰時期還有一些雙發戰鬥機比較與眾不同，它們就是夜間戰鬥機。

雖然這些歷史上的夜間戰鬥機全部採用的都是最傳統的兩側翼掛螺旋槳，但是它們一個個卻都戰績亮眼，這是為什麼呢？為什麼它們明明應該要機動性能潺弱的動力佈局卻能得此佳績呢？原來是到了夜晚的時候，基本上已經幾乎無法依靠目視的方式進行空戰了，甚至連戰鬥機對戰鬥機的空中格鬥都基本無法進行，而大多數的夜戰型態都是用來攔截追擊敵方的轟炸機等大型飛機。因此戰機的機動敏捷性並不重要，甚至於是無所謂。因為夜間攔截戰鬥更加依靠的是機載雷達等電子設備，而當時的這些雷達設備也只有雙發動機以上的飛機才有能力承載得起。於是這些夜間戰鬥機雖然看起來笨拙遲鈍(實際上也真是如此)，卻能夠在黑暗的夜晚取得成績，而敵人那更加敏捷的戰鬥機卻拿它沒好辦法！

除了像 P-61 黑寡婦這種從設計之初就是夜間戰鬥機的情況之外，也有不少夜間戰鬥機是由其他的雙發飛機改裝而來。例如前面才被我們嫌棄的 Bf 110，後來就被加裝雷達(從 Figure 17 中可以明顯看見在機頭處突出的雷達天線)而成夜間戰鬥機，取得的戰果不知輝煌與否，卻肯定比先前作為普通戰鬥機使用時更好用多了！

不過復盤過來其實也不難發現，這種專職的夜間戰鬥機之所以能夠如此綻放風采，也是因為正巧遇上了時代的機遇，而在那個時代之後、或之前，都再沒有它獨領風騷的舞臺。在時代之前，那是因為雷達科技還不夠發展水準或甚至根本沒有，因此不可能造出這種專司夜戰的戰鬥機。而在時代之後，包含雷達在內的各種電子系統其體積重量不斷縮小且愈趨發展成熟，連普通的戰鬥機都可以隨機搭載配備；當阿貓阿狗大家都有的時候，單獨設置的夜間戰鬥機就失去了它的最大優勢所在，甚至於讓戰鬥機的可用工作環境已經不滿足於應付夜晚，而逐漸發展成所謂「全天候戰鬥機」。因此就是在那個剛剛好的時代，雷達設備已經具有一定水準，卻還不足以讓普通飛機大量裝配攜帶，使得原本笨拙的夜間戰鬥機可以利用其承載力強的優勢搭載裝配雷達設備，形成一種你看不見我但我卻看得見你的單方面優勢！

一些其它的構想

最後讓我們來看一看設計師 Kelly Johnson 當初在設計 P-38 之前的一些構思草圖，揣測回顧他當時的一些想法和顧慮，藉此再進一步了解各種雙發戰鬥機方案的優劣取捨。當然其它的飛機設計者肯定也會有各種想法顧慮與斟酌存在，只不過當前還能夠容易找到相關記錄與說明的只有 P-38 而已，因此才讓我在這裡只拿 P-38 的設計來說事。

Figure 18. P-38 在設計當時曾經構思考慮過的數種動力佈局方案草稿 ^[16]

Figure 19. 使用了更加漂亮的方式繪製的 P-38 動力佈局草案 ^[16]

上圖(Figure 18 和 Figure 19)列出了 6 種飛機構型的概念草圖。其中的 1 號就是最主流的雙發動機設計方案，以當時來說是技術最成熟，經驗與資料最豐富，不過缺點也是相當明顯，在前面都已經深入探討過，因此最後的 P-38 並沒有採用 1 號方案。 4 號方案則是最終 P-38 所決定採用的方案，好壞優劣在前面也都探討過，就不再多做說明。

2 號與 3 號方案其實是一樣的，只不過一個螺旋槳後推而一個前拉而已。但是注意它與 1 號大不相同，可以明顯看到螺旋槳軸的部份相當纖細，根本不可能是放得下發動機的空間。事實上這兩個方案的發動機是安裝在中央機體內一前一後的，然後透過幾組延長軸與齒輪的連接，將動力傳導至兩側螺旋槳。這個方案其實相當聰明，既得到了翼掛螺旋槳的便利，又因為發動機安置在中央機身而沒有滾轉率衰退的缺點，只不過因為透過多個延長軸等機械結構傳遞動力的不可靠性與故障可能的問題，而最終並沒有採用這個構想。

6 號方案則是前拉加後推的動力佈置，與前面介紹過的 Do 335 基本屬於同一種款式。除了兩側延伸結構與尾翼等可能會導致(相較於 Do 335 那樣的構型)多餘的阻力之外，其對戰鬥機的性能來說應該是最為理想的方案。而很可能當時也是考量到和前面探討 Do 335 動力佈局複雜性一樣的問題，再加上創新構想缺乏足夠的經驗積累，以及研發時程不夠充裕的壓力的緣故，因此讓 P-38 最後沒有採用此種方案。

5 號方案則相當特別，相當不對稱，它看起來就是將兩個正常的單發戰鬥機給一左一右拼起來而成的合體戰鬥機。雖然最終並沒有被 P-38 採用，然而這個方案卻曾經被歷史上的其它設計給採用過，例如實驗性質的 XP-82 雙野馬(Figure 20)。既然反正 P-38 最後也沒有使用這種方案，咋也不確定人當時怎麼想的，那就來看看採用這方案的 XP-82 的想法吧！ XP-82 雙野馬在設計概念上就是把經典的兩個 P-51 野馬給左右拼起來。這種真雙胴(雖然 P-38 一直都被稱為雙胴戰鬥機，但是放在 XP-82 旁邊的話就只能算是假雙胴了！) 戰機甚至有兩個對稱的駕駛艙室和兩個飛行員，可以互相分擔雙發戰鬥機超長航程的體力和精神負荷，同時也是對於不對稱駕駛位能否正常操作戰機的試驗。然而從結論來看，除了試驗飛行之外，XP-82 從未實際正式列裝過部隊，似乎也就說明了這個方案經不起實用性的考驗，最終還是被淘汰！只不過這種獨特設計的曾經存在也確實帶給航空愛好著驚奇與討論的話題。

Figure 20. 看似將兩臺經典的 P-51 野馬式戰鬥機左右拼裝起來而成的 XP-82 雙野馬戰鬥機 ^[17]

總結

本篇探討了螺旋槳戰鬥機採用雙發動機所帶來的好處與壞處。雙發方案可以增加動力的供應，使得在加速性與極速方面俱備優勢，也由於更高的酬載力而能得到更遠的航程和更強大的武器威力；然而因為轉動慣量大的問題導致姿態操作的反應能力不佳，空戰所需的機動性能大不足，使得作為戰鬥機使用時往往趨於弱勢下風。而這也解釋了為什麼明明雙發動機可以解決許多問題，然而歷史上的眾多戰鬥機卻往往堅持在單發動機方案上面死磕到底的原因！

此外本篇也介紹了歷史上曾經出現過的數種雙發戰鬥機的方案，回顧當時人們的顧慮與巧思。然而說到底，雙發動機之所以會導致這樣那樣的嚴重問題，根本原因還是因為螺旋槳的盤面尺寸太大所導致。至於到了現代的噴氣式戰鬥機，因為發動機直徑相比螺旋槳盤面大幅縮小的緣故，就不再那麼糾結單發或雙發方案了，甚至最新的戰鬥機款式還能有三發動機的呢！

螺旋槳 10：螺旋槳佈局

Sat, 06 Dec 2025 16:54:13 +0800

在有了螺旋槳之後，該以什麼樣的方式將螺旋槳放在飛機上呢？其實在前篇 ^[1] 已經探討過其中的一部份了，而本篇將要來看看更多關於螺旋槳飛機的動力佈局設計。

單槳前拉佈局

使用單一螺旋槳的前拉式佈局大概是我們最常見的螺旋槳佈局之一，其大量被應用在各式小型飛機上面。有關前拉式螺旋槳的好壞優劣在前篇都已經仔細的分析過了 ^[1]，總結而言前拉式螺旋槳特別適合使用在小型飛機上，其與傳統的尾翼式機翼佈局相當天然搭配，穩定性設計上的困難較少也較容易，低速下的操控性較佳，並其相較於與它相對的另一種佈局(後推佈局)來說少了許多的問題與難處。

Figure 1. 採用單槳前拉螺旋槳佈局的 P-40 戰鬥機 ^[2]

Figure 2. 採用單槳前拉螺旋槳佈局的 Fw-190 戰鬥機 ^[3]

Figure 3. 採用單槳前拉螺旋槳佈局的 Cessna 172 民用小飛機 ^[4]

單槳後推佈局

後推螺旋槳佈局也曾經在前篇分析過 ^[1]，也是部份小型飛機可能會採用的推力佈局。總結而言後推螺旋槳的推進效率高，連帶使得在最高航速、航程、和經濟性等方面的表現都優於它的對照組(前拉佈局)。而其缺點為低速操控性較差，並且在設計與使用上的各種大小問題與難處比較多，比如說需要更長的起降跑道，螺旋槳更容易觸地，不能採用後三點式起落架，也往往需要更長些的起落架，因為會使飛機重心靠後而一般較難適配傳統尾翼佈局，以及在跳傘的用途上較具危險性等等。

雖然因為這樣那樣的問題比較多而使得一直以來只有少數飛機會嘗試使用後推佈局，然而在近年這種佈局卻被大量應用在無人飛機上，大量曝光於大眾面前。究其原因為目前無人飛機大多不需要多強悍的低速操控性能或戰鬥機動性能，反而它的高經濟性能夠帶來更多的好處，並且無人飛機一般體型比通常的飛機小，使得與起落架相關的問題較不明顯，因此造就了曾經較為冷門的後推式佈局卻在今日大量出現在無人飛機身上的結果。

Figure 4. 使用單槳後推螺旋槳佈局的 Velocity XL 民用小飛機，比起傳統佈局的小飛機其經濟性和航程稍具優勢 ^[5]

Figure 5. 另一款採用雙發後推佈局的 Beechcraft Model 2000 Starship 商務飛機。雖然也能將它歸類為翼掛佈局，但其整體配置和表現更加接近於所謂的純後推佈局 ^[6]

Figure 6. 二戰末期開發的 J7W1 震電戰鬥機，採用後推螺旋槳搭配鴨翼的佈局，令它的極速能達到 750 km/h，比採用傳統佈局的其它對手高出一截 ^[7]

Figure 7. 當代無人飛機最大的需求就是穩穩的飛行，因此讓這方面表現優異的後推式佈局突然成為主流。圖中為 MQ-9 死神無人機 ^[8]

翼掛佈局

把螺旋槳(連同發動機)掛在機翼上也是相當常見的一種配置。當飛機的動力需求上升，一臺發動機、一副螺旋槳無力負擔的時候，自然就要增加螺旋槳與發動機的數量，此時顯然機頭是堆不下了，於是就自然而然再正常不過的就往機翼上面放了。另一方面，螺旋槳與渦輪噴氣發動機不同，螺旋槳具有非常巨大的盤面，因此另一原因也是除了主翼之外，在佈置上其實也沒有太多可以選擇的其它地方能安放螺旋槳。這就是為什麼幾乎所有使用複數螺旋槳的飛機大多都採用翼掛佈局的原因。

Figure 8. 正在翻滾的 A-10 攻擊機，可見其滿滿的炸彈等武器全被佈置懸掛在主翼下 ^[9]

除了缺乏其它可供螺旋槳容身的選擇之外，翼掛螺旋槳佈局本身也是具有些好處的。機翼的位置一般恰好都在整機的重心所在處(或者其實應該說主機翼都會設計安放在重心位置上)，因此許多重型酬載一般也都喜歡安置在機翼位置處。比如能夠掛載大量武器的著名攻擊機 A-10 (Figure 8)。因為掛架剛好就在重心上，因此裝上炸彈、丟下炸彈、或者更換不同大小重量的炸彈，基本不影響飛機的平衡性；同理也是為什麼大部份飛機都喜歡把油箱塞在機翼裡面的主因之一。將炸彈或油箱換成發動機其實優點相同，在這種配置下無論想安裝多少發動機都行(當然是在結構撐得住的前提下)，想更換大的或小的發動機都沒什麼困難，對於整機的平衡性影響干涉少，設計佈置的使用彈性很大。再加上佈置在機翼上的發動機自身的重量，可以很大程度的抵消整片機翼產生的升力在翼根處所造成的彎矩 (或者從另一個方向來理解，那就是將整機的重量更加均勻的平攤到機翼上)，能夠相當程度的降低翼根處的結構負擔，節省結構重量。

當然翼掛佈局也不都是好處的，其中一項明顯的缺點就是翼掛的螺旋槳通常都會距離飛機的中軸線有相當距離。在平常正常的時候倒不是什麼大問題，但當有一側發生故障而喪失推力的時候，就會給飛機帶來相當的偏航力矩。此外質量相當大的發動機被佈置在遠離中軸線的位置，也會給飛機產生大得多的轉動慣量，對於運動性能有所要求的飛機來說這會給飛機帶來相當大的性能劣化；不過對於不甚講究運動性能的大型飛機來說倒是無傷大雅就是了。

因此最終，對於那些需要安裝兩臺以上發動機(及依附的螺旋槳)的飛機，特別是對於那些大型的飛機來說，在沒有其它特別考量因素的情況下，自然而然的就通通都喜歡採用翼掛佈局。

Figure 9. Lancaster 轟炸機，四具發動機和螺旋槳都佈置在機翼上 ^[10]

Figure 10. 將螺旋槳佈置在主機翼上幾乎是所有雙發以上飛機的默認佈局，圖為 B-29 轟炸機 ^[11]

此外也有部份飛機雖也將發動機置於機翼上但採用螺旋槳後推式設計。但是因為動力安置在機翼上，不像前面單槳小飛機採用前拉或後推會給整架飛機帶來翻天覆地的改變，因此我們一般仍稱這些飛機採用翼掛佈局，或者翼掛後推佈局，而不將它們歸類為純粹的後推式佈局。

Figure 11. 雖然使用後推螺旋槳，但在佈局分類上仍屬於翼掛佈局的 B-36 轟炸機 ^[12]

Figure 12. 同樣採用後推螺旋槳加鴨翼的設計，但相比前面介紹的 Beechcraft Starship，Piaggio P.180 更加接近於傳統翼掛佈局 ^[13]

上揹佈局

有些飛機會選擇將螺旋槳佈置在飛機的背上。將動力裝置放在機身上方，會因為推力軸線遠離飛機重心的關係而產生使飛機低頭的下壓力，對於飛機平衡和穩定的負擔較大。並且不同於噴氣發動機，螺旋槳因為其巨大盤面的關係，往往還得將動力裝置的位置安置的更高，更將加劇前述的不平衡力矩。因此這種動力佈局在一般能夠有其它選擇方案的情況下，都不會被採用。那麼什麼情況下會讓飛機採用這種佈局方式呢？顯然就是有些特殊用途需求的飛機了！

比如水上飛機，為了避免濺起的水花或水浪對動力裝置的運作造成影響或甚至造成損壞，因此會傾向於將螺旋槳和發動機往高處安放，於是就跑上機背了。此外動力滑翔機也是經常能見到採用上揹式佈局的飛機。對於滑翔機而言，動力多半只是短時間幫助自己起飛並獲得初始高度的需求，因此可以將就接受一些在正常飛機上會顯得比較尷尬的設計。並且相比於常規螺旋槳在機頭的佈置，支撐在背上的螺旋槳還能在不用的時候很方便的被收折在機身裡(如圖 Figure 16)，且對於揹在背上的螺旋槳所造成的低頭力矩，又在滑翔機普遍有著長尾巴的情況下而能夠相當輕易的被平衡下來，因此讓此種螺旋槳佈局方式相當常見於動力滑翔機上。

Figure 13. 歷史上曾經短暫存在過的大型水上飛機 Dornier Do X，其 12 具螺旋槳全都架在主翼上方的高處 ^[14]

Figure 14. 二戰時期相當有名的 Catalina 水上飛機也採用上揹式動力佈局，不過因為它的機翼也一同被架高在同一位置，所以也能分類為翼掛式佈局 ^[15]

Figure 15. ASH 26 滑翔機高舉在機背上的螺旋槳正在運轉 ^[16]

Figure 16. ASH 26 滑翔機的近照，可以看見機身在螺旋槳後方的收納空間和蓋板，螺旋槳會在不需要運作的時候被收折進這個空間裡面 ^[17]

混合式佈局

基本的螺旋槳佈置方式種類並不多，主因還是因為較大的盤面尺寸，導致能夠發揮創意的空間並不太多。但這並不表示螺旋槳佈置就永遠中規中矩，有時候我們還是能夠見到許多看著奇特的螺旋槳配置方式，其中大部份為混合將不同的佈局使用在一起。所以這裡就讓我們來欣賞一些比較奇特少見的螺旋槳佈置方案。

機首前拉加翼掛

把螺旋槳同發動機放到主翼上的好處在前面已經解釋過了。然而如果飛機正好不大不小，雙槳拉不動，四槳又太多，正好三槳最合適的話那該怎麼辦呢？當然一個理所當然的做法就是寧可冗餘也不要不足，雖然我只需要 3 個螺旋槳，但裝上 4 個又有何不可呢？可是有的時候人們並不這麼想，而是硬要在三槳的方案上死磕，於是就誕生了這樣一種混合佈局方案：大翼上掛兩顆螺旋槳，剩下一個則比照傳統前拉佈局裝設在機頭。

這麼做的好處就是動力需求適當，不必因為其實不需要的另一臺發動機而承受多一份重量和油耗等負擔；然而缺點也相當明顯，混合式的佈局在設計上帶來了更多的複雜度和計算與平衡，在使用與維護上的複雜性也會一定程度上升。

Figure 17. 二戰時期經常亮像出場的 Junkers Ju 52 運輸機就是採用翼掛加機首前拉共三具螺旋槳的運輸機 ^[18]

翼掛加垂尾上吊

與前面介紹的佈局類似，也是為了在飛機上採用三螺旋槳而生的方案。只不過咋也不知道人家當時怎麼想的？竟把第三具螺旋槳(及發動機)安裝在垂直尾舵上！除了與其它三槳飛機同樣會面臨到的複雜度上升之外，相比於前一種配置方案，將第三具發動機安裝在垂直尾舵上的設計還會遭遇到更加嚴重的結構負擔、平衡性配置、以及與上揹式佈局一樣的低頭力矩問題，大概唯一的優點就是機頭前方視野比較開闊了。

因此這種兩翼加垂尾上吊的佈局被採用的產品著實真不多，而有幸這少見的型號就曾被臺灣本地的航空公司所採購使用。當年的台灣航空(人家公司的名稱就叫作「台灣航空」，常被簡稱「台航」)就曾引進過一批採用這種動力佈局的 Britten-Norman BN-2A Mk III Trislander 飛機，可搭載 18 人，專飛離島航班。只不過這型號的飛機早已退出臺灣的客運服務，曾經的台灣航空如今也已不復存在，不過還有一架退役的 Mk III 型 BN-2 靜態展示在臺東豐年機場的某處草坪上(Figure 20)，讓我們還有機會一睹其風采。

Figure 18. 罕見採用翼掛加尾吊的三槳 BN-2A Mk III 小客機 ^[19]

Figure 19. 從側面觀看 BN-2A Mk III，能更清楚觀察到為了支撐尾螺旋槳而特別加固結構的垂直尾翼 ^[19]

Figure 20. 在臺東豐年機場展示的，曾飛翔於離島天空的罕見三槳小客機 ^[20]

前拉加後推

從前曾經就有關前拉式或後推式螺旋槳的優劣利弊進行過比較分析 ^[1]，兩種佈局各有優缺點。那麼我把兩種佈局一起用上，是不是兩種佈局的優點就通通都有了呢？是的，可以這麼做，於是有那麼一小部份的飛機就採行了這個方案，即前拉加上後推的動力佈局；只不過在得到兩種佈局的優點之外，兩種佈局的缺點也會一起得到就是了！

前拉螺旋槳的存在可以使飛機在較低速度的狀態下依然提供機翼和操控舵面一定程度的氣流供應，也就是低速的操縱性可以一定程度的保留，起飛降落所需要的跑到長度也不會過長。在巡航的狀態下可以透過油門和槳距的調節，將更多的動力配置比例依靠在後推的螺旋槳身上，也能夠一定程度的提升巡航經濟性。

至於說到缺點那也是挺不少。後推螺旋槳本身具有相當優越的航行效能，然而因為前拉螺旋槳的存在，其效率自然不若純粹的後推佈局來得優越；同樣其前拉螺旋槳為飛機保留了些低速狀態下的性能和操作能力，然而此時的後推螺旋槳卻對此沒有什麼助益，只能夠作為推力補充的角色存在，然相比於其之存在所產生的機體體積重量負擔，效益也不若採用兩具都是前拉螺旋槳的條件來得優越。總體而言就是這種混合佈局同時具有前拉與後推的優點，但性能卻不及於純粹的前拉或後推方案。此外還有動力系統的複雜化，在設計、維護、與操作使用的複雜度都高於採用兩具發動機翼掛的方案。因此這樣的動力佈局也是屬於相當罕見的一種，特別是在商用飛機上；至於軍用飛機，這個話題值得好好深入探究一番，就留待後面主題再行探討了。

Figure 21. 罕見採用前拉加後推雙槳的 Cessna P337G 小飛機，圖為軍用版的 T337H ^[21]

螺旋槳 9：通用噴流推進原理

Sun, 09 Nov 2025 01:27:43 +0800

連著好幾篇螺旋槳的性能計算比較，不知會不會有些人覺得太複雜困難，感覺要把頭給看暈了？那麼本篇我就來換個思路，從完全不同的另一個角度來探討噴氣推進的原理。更有意思的是，本篇要探究的原理還非常簡單、好懂，並且能夠套用在幾乎所有採用噴流原理的推進裝置，不論是螺旋槳、渦輪噴射、渦輪風扇、或是直昇機還是火箭等等，只要是利用流體的反作用力來作為推進手段的通通都能夠適用！

Figure 1. 透過從前方吸入流體(空氣或水等)並加速向後吐出而獲得反作用力的動力裝置

上圖(Figure 1)就是本篇所探討的動力裝置的原理示意，從前面吸入流體然後將流體加速並從後方噴出，藉此獲得反作用力，也就是我們所想要的推力。這動力裝置具體是什麼並不重要，就是個黑盒子，裡面可能是螺旋槳，可能是渦輪噴射發動機，或其它任何不同運作原理的設備，反正只要符合前吸後吐的反作用力原理的通通都能套用。

遊戲體驗

暫時拋開那些數學計算式不談，這裡我們用一個娛樂遊戲來幫助理解基於反作用力的推進原理。這個遊戲一般讀者需以自己的生活經驗去做想像，但如果有條件的話，實際玩一下也許效果會更好！

Figure 2. 俗稱叫大龍球的大型遊戲球 ^[1]

Figure 3. 常見可用來推拉貨物的小型板車 ^[2]

有沒有玩過或看過像上圖(Figure 2)那種和人差不多大的遊戲球(瑜珈球/大龍球)呢？還有在生活中經常出現用來搬運物品的推板車(Figure 3)，也許很多人小時候都喜歡站或坐在這種車上玩吧！那麼我們就假設現在有一個很大的平面遊戲室，空間非常大，大到可以讓你在裡面隨便划，並且裡面均勻隨機的散落著許多上圖那種大龍球。然後我們就像下圖(Figure 4)一樣躺在推車上對著大龍球用力踢，球就會以一個相當快的速度被我們踢走，然後我們躺的小車也會因為反作用力的緣故而向後移動。如此不斷重複，我們的小車就可以在整個空間裡面到處跑來跑去。

Figure 4. 躺車上用腳奮力踢球

Figure 5. 躺車上愜意用手扒拉球

但是這樣做有一個缺點，可能很快就會累！那麼要怎麼樣能夠讓我們用更加輕鬆的方式來翱遊在整個地方到處亂跑呢？最有效的方法就是不要那麼用力的踢球，而是要保留力氣放輕一點力道，最好是像上圖(Figure 5)那樣愜億的躺在小車上，用手隨便扒拉一下球就可以了。這樣如果可以搭配一杯藍山手沖冰紅茶，再加上一隻可以滑的手機，說不定能讓人扒拉一整個下午的球！

但是這樣有一個缺點，推球的力道小了就讓我們的小車跑的也慢了！如果我希望能一樣省力但是速度不要減少的話，有沒有什麼方式可以讓我們達成這種願望呢？有的，我們只需要提高小車在空間中遇到球的機會就可以了！原來我們的球是均勻散佈在整個空間的，也許按照原來的速度，我們可能比方說每隔平均 30 秒才會遇到一顆球，那麼如果想辦法讓我們可以每隔 5 秒鐘就遇上一顆球的話，是不是就可以一樣又省力又不會跑的慢了呢？於是這裡就有一些可以讓我們碰上大球的頻率提升的方案：

首先最直接的就是買多一點大球放到我們的遊戲室裡面去(Figure 6)。在假設球的放置均勻的前提下，那麼當球的數量大幅增加時，我們溜車的過程中能遇到球的時間也就跟著縮短了。這樣就可以同樣使用輕鬆省力的方式去隨意扒拉推球，然後靠著多推幾顆球來維持想要的速度(推進力)。對應到現實，其實就是當流體密度愈高的時候推進效率愈好！

Figure 6. 當球的數量更加多且密集的時候(圖右)，就可以使用省力的方式多推幾個球

增加大球的數量挺簡單直接，但是如果我沒有財力買這麼多的球回來玩的話呢？第二個方案就是讓你手臂伸長一點(Figure 7)，不要只滾到小車旁邊的球你才願意推一下，而是手臂伸出去凡能夠碰到的球你都推一下。這樣的話雖然球的數量沒有增加，但是我們能夠推到球的頻率依然增加了，相比於懶惰的我們只願意推一下那已經滾到車子邊上的球而言，我們就可以用輕推的力道依然維持住車子的速度(推進力)。對應到現實，其實就是當推進裝置吸氣吐氣的截面積愈大的時候推進效率愈好！

Figure 7. 將手伸長出去(圖右)可以觸及更多的球，就能使用省力的方式多推幾個球

前面兩個方法都很好，但如果我就是窮又手短，沒辦法買更多大球，手伸出去也沒多遠距離，真的就只能拍到已經到小車子旁邊的球而已的話，還有辦法嗎？

前面兩個方法的作用其實都是一樣的，就是想辦法增加我們在一定時間裡碰到球的機會，而上面第二個方法就是在無法增加大球數量的前提下，主動展開手臂增加捕球的範圍，等於是往橫向加大捕球的空間。但是再想想，好像也沒有規定說只能往橫向增加捕球範圍啊？！如果我縱向往前增加捕球範圍可不可以(Figure 8)？得，這就是現實上增加航速可以增進推進效率的原因！

在剛開始速度不快的時候會比較辛苦吃力，也或許我們可以使用一些無賴作法，比如說一開始用腳直接蹬地板等。但是當速度一提上來，當速度達到平常幾倍快的時候， (考量我們的小車在不同速度下可能阻力沒差太多的情況) 可能就會發現反而又省力了！所以在高速行進的情況下推進效率會得到提升的原理其實與前一個伸開雙臂的原理是一樣的，只不過前法是往橫向擴展抓球的空間，而本法是往縱向往前方延伸抓球空間。

Figure 8. 與直覺相反，當移動的速度更快的時候(圖右)，反而因為可以捉到更多的球而能夠使用更省力的方式推球

推導證明

前面的部份以一種接近一般人能夠身體感知的方式來解釋噴流推進，但是可能太過於不嚴謹，並且其實當中有些特性可能是和一般人直覺經驗相反的。因此這一部份將站在比較正經的角度，以簡單的數學來解釋和證明噴流推進的特性。

首先我們假設有一個推進裝置如下圖(Figure 9)所示。它就是一個黑盒子，裡面是什麼原理我們不知道或不想知道，反正它從前方吸入流體(空氣、水、或其它)，並將流體加速之後從後方噴出。其中特別注意，如果這裝置的前方存在一個聚集收攏氣流的現象，或者後方存在一個聚集噴流的現象，那麼我們所假設的這個裝置的體積就可能會大於裝置實際的空間體積，比方螺旋槳就是這類比較明顯的例子(Figure 10)。

Figure 9. 流體進入一個黑盒子並加速離開，產生反作用力作用在黑盒子上，即推力

Figure 10. 螺旋槳前、後聚集氣流的空間

推力

那麼這個裝置能夠產生多少推力呢？因為我們假設了的裝置含括了前、後氣流收縮或擴張的範圍，因此可以確定這個虛擬範圍的前入口與後出口之壓力都與環境壓力相同，因此無需考量，那麼推力的來源就只剩下流體增速所帶來的反作用力了。依據牛頓第二運動定律即「力等於動量變化率」的關係，即可列出裝置所產生的推力(F)如下：

\[ F = \frac{ M_o V_o - M_i V_i }{dt} \]

其中：
$dt$ 為假定的一段非常短的時間差；
$M_o$ 為在 $dt$ 時間裡面被吹出的流體質量；
$M_i$ 為在 $dt$ 時間裡面被吸入的流體質量；
$V_o$ 為裝置出口的流體速度；
$V_i$ 為裝置入口的流體速度。

接著繼續解算：

\[ F = \frac{ M_o V_o - M_i V_i }{dt} \] \[ F = \frac{ ( \rho_o A_o V_o dt ) V_o - ( \rho_i A_i V_i dt ) V_i }{dt} \] \[ F = ( \rho_o A_o V_o ) V_o - ( \rho_i A_i V_i ) V_i \]

其中：
$\rho_o$ 為出口流體密度；
$\rho_i$ 為入口流體密度；
$A_o$ 為流體出口截面積；
$A_i$ 為流體入口截面積。

這式子看上去簡單，但再稍微細看又發現有點不對勁，因為假設的未知變數太多了！特別是有些變數值還是虛擬的，比方螺旋槳前面後的聚氣空間範圍，連想測量都困難！然而我們知道質量是不滅的，不管上面那些具體變數多麼不確定，只要這個動力裝置可以穩定的持續運作，那麼流體的吸入流量肯定等於吹出流量；否則吸入比吹出多，這裝置可不得爆炸？吹出比吸入多，難道這裝置還能憑空產生流體？因此我們可以將許多變數濃縮轉化成一個變數，也就是流體質量流率($\dot{m}$)，即每個單位時間裡面通過這個裝置的流體質量，並且這個數字肯定不管在吸入端、吹出端、或是裝置裡面都會是一樣的。那麼上式就可以寫為：

\[ F = ( \rho_o A_o V_o ) V_o - ( \rho_i A_i V_i ) V_i \] \[ F = \dot{m} V_o - \dot{m} V_i \] \[ F = \dot{m} ( V_o - V_i ) \]

如此就得到一個非常簡單的推力計算方式，只需要知道吸氣速度、吹氣速度、和質量流率即可計算出推力，並且對於這三個參數的實際測量也不存在太大的困難性。

功率

除了推力之外我們還得計算前後氣流的能量差，畢竟前面進來的流體到了後面能夠得到更多的能量，這能量肯定得由我們的裝置提供，很自然的我們會想知道究竟需要提供多少能量給它？那麼我們所需要輸入的能量，也就是氣體在進出口之間的能量差(E)是多少呢：

\[ E = \frac{1}{2} ( \dot{m} \cdot dt ) V_o^2 - \frac{1}{2} ( \dot{m} \cdot dt ) V_i^2 + C ( \dot{m} \cdot dt ) ( T_o - T_i ) \]

其中：
$T_o$ 為出口流體溫度；
$T_i$ 為入口流體溫度；
$C$ 為一個代表性質的流體比熱容。

Tip	其中上式流體的比熱容($C$)是一個代表性質的比熱容，其具體數值在這裡不重要，畢竟我們不知道它在裝置裡面是如何升溫的，也不知道是否有汽化等過程或甚至化學反應等參與。因此無需糾結該數值具體應是多少？而其在本篇中更大的作用是作為示意溫度的角色而存在。

當然如同我從前敘述過的 ^[3] ，其實多少能量不是我們關心的事情，我們真正關心的是能量率(W)。於是上式可以繼續變化為：

\[ W = \frac{E}{dt} = \frac{1}{2} \dot{m} V_o^2 - \frac{1}{2} \dot{m} V_i^2 + C \dot{m} ( T_o - T_i ) \] \[ W = \dot{m} \left( \frac{1}{2} V_o^2 - \frac{1}{2} V_i^2 + C ( T_o - T_i ) \right) \] \[ W = \dot{m} \left( \frac{1}{2} ( V_o^2 - V_i^2 ) + C ( T_o - T_i ) \right) \]

如此我們就得到了上面那樣的裝置進出口流體的能量差，也就是為了維持這裝置的推進作用而需要我們投入的功率輸入(可理解對應為燃料的消耗速度)。

效率

有了推力、有了輸入功率，接下來自然要計算一下投入回報比也就是效率是多少了！但是輸入功率有了，推進的功率是多少呢？按照機械功定義，功率為力乘(內積)移動速度，因此推力乘上(內積)飛機的飛行速度(或船舶的移動速度，以此類推)就是了。那麼飛機的飛行速度多快呢？欸這可不就是前面氣流進入的速度($V_i$)了嗎？

因此上面這套動力裝置的推進效率($\eta$)即為：

\[ \eta = \frac{ F \cdot V_i }{W} \] \[ \eta = \frac{ \dot{m} ( V_o - V_i ) V_i }{ \dot{m} \left( \frac{1}{2} ( V_o^2 - V_i^2 ) + C ( T_o - T_i ) \right) } \] \[ \eta = \frac{ ( V_o - V_i ) V_i }{ \frac{1}{2} ( V_o^2 - V_i^2 ) + C ( T_o - T_i ) } \] \[ \eta = \frac{ ( V_o - V_i ) V_i }{ \frac{1}{2} ( V_o + V_i ) ( V_o - V_i ) + C ( T_o - T_i ) } \]

我們可以從上式裡發現出現了許多兩數值相減的項目。這點很重要，因為這表示我們所希望知道的這個效率，可能其中許多成份與流體進出的具體速度多少無關，而與它們之間的差值有關；溫度的部份亦同，這可能表示進出氣流的溫度多少其實並不重要，而是它們之間的差值才有意義。於是我們就加入兩個新符號分別表示進出口的速度差值($\Delta V$)與溫度差值($\Delta T$)：

\[ V_o = V_i + \Delta V \] \[ T_o = T_i + \Delta T \]

那麼上面的效率算式就可以繼續整理下去：

\[ \eta = \frac{ ( V_o - V_i ) V_i }{ \frac{1}{2} ( V_o + V_i ) ( V_o - V_i ) + C ( T_o - T_i ) } \] \[ \eta = \frac{ \Delta V \cdot V_i }{ \frac{1}{2} ( \Delta V + V_i + V_i ) \Delta V + C \cdot \Delta T } \] \[ \eta = \frac{ \Delta V \cdot V_i }{ ( \frac{1}{2} \Delta V + V_i ) \Delta V + C \cdot \Delta T } \] \[ \eta = \frac{ \Delta V \cdot V_i }{ \frac{1}{2} \Delta V^2 + V_i \cdot \Delta V + C \cdot \Delta T } \] \[ \eta = \frac{1}{ 1 + \frac{\Delta V}{ 2 V_i } + \frac{ C \cdot \Delta T }{ \Delta V \cdot V_i } } \]

至此算是把效率的計算式整理好了。這個算式不只可以算出效率而已，更重要的是我們能夠從這式中清楚的看出各項變數在其中所扮演的角色。比如這條式簡單而明確的告訴我們效率必定是一個小於 1 的數值，這很符合我們對於效率的理解 ^[3]。此外我們的動力裝置對流體加速的幅度愈大則效率愈差，對流體增加的溫度愈多則效率愈差；但是如果這裝置在一個環境流速更高的地方工作則有助於提升效率！

性能改善

無論是喜歡遊戲說明的還是喜歡數學證明的，經過前面的說明講解，想必已經對任何利用流體反作用力產生動力的裝置有了足夠程度的了解。那麼借下來就要以前面的論述為基礎，繼續探討各種動力裝置的性能，以及可能改善性能的方向。

首先把前面所推導得到的兩項最主要的結果，也就是推力($F$)和效率($\eta$)的計算式整理如下：

\[ F = \dot{m} \cdot \Delta V \] \[ \eta = \frac{1}{ 1 + \frac{\Delta V}{ 2 V_i } + \frac{ C \cdot \Delta T }{ \Delta V \cdot V_i } } \]

要給飛機增加性能則通常動力裝置需要增加推力，而從推力式可以看出，若要增加推力的話，無論是增加質量流率($\dot{m}$)或者增加流體加速程度($\Delta V$)皆可。其實當渦輪噴射引擎剛出現在世界上的時候為什麼立刻就能傲視群雄？就是因為在當時它能夠提供傳統動力裝置(螺旋槳)所完全無法匹敵的 $\Delta V$，因此才給飛機帶來了讓人嘆為觀止的推力與速度。

但是吧，從效率式也能看出來 $\Delta V$ 的極大化在給予強大動力的同時，也會讓產生動力的效率降低到令人髮指的地步，而這就是早期純渦輪噴射引擎的效率為什麼這麼破爛的原因了！ (並且純渦噴發動機還不只 $\Delta V$ 大而已，甚至還給排放的尾氣提高了非常多的溫度 $\Delta T$，因此效率進一步劣化！) 那麼我們能不能夠既想要動力大，又想要效率好呢？這就需要將目光看向推力式的另一個元素即質量流率($\dot{m}$)了。

重新整理質量流率的計算式如下：

\[ \dot{m} = \rho_i A_i V_i = \rho_o A_o ( V_i + \Delta V ) \]

從上式很明顯就能夠看出來，在打算降低 $\Delta V$ 的前提下，想要提高或維持流體質量流率的話可以從幾個方面著手：流體密度($\rho_i$ 和 $\rho_o$)愈大愈好、裝置吸入與排出流體的截面積($A_i$ 和 $A_o$ ，為了減少饒口的敘述，後面將以更形象化的詞語「口徑」來稱呼，就是和炮管的口徑一樣的意思) 愈大愈好、和吸入流體的速度即我們飛機(或船)航行的速度($V_i$)愈高愈好。如果還有什麼別的事項的話，那麼就是離開的流體溫度升高($\Delta T$)愈少愈好，最好是不要有升溫；降低流體升溫這點雖然從上式看不出對推力有什麼影響，但是對於效率的改善有影響！

前面所列出改善方向的其中前三項，在之前的遊戲裡面其實都已經很形象的解釋過了，對其之影響原理應該不陌生。對應到現實上來說明，流體密度愈大則效率愈好。這就是為什麼飛機無論怎麼跑，效率都無法比得上在水上跑的船的原因，而我們一般人比較能夠感知的貨運價錢就能夠良好說明這項特性。同樣以在空氣中飛行的飛機來說，低空密度高的空氣環境也有利於提高飛機動力裝置的推進力與效率 (看到此處如果會感覺到疑惑的讀者請稍待，後面會說明)。

動力裝置的口徑也是愈大愈好。這樣的特性其實在前篇 ^[4] 的螺旋槳分析中已經表現出來了，而在本篇更採用另一個思路從另一個方向進一步證明對於所有(反作用力式)的動力裝置都存在這樣的特性，當口徑愈大的時候無論推力或效率都能有效的增進。這就是為什麼使用螺旋槳的飛機在一般中低速情況下推進效率最高也最省油的原因了，就是因為螺旋槳可以被造的很巨大；同樣的從渦輪噴氣式發動機被發明應用以來，為什麼發動機口徑(特別是在商用飛機上)愈造愈大的原因，就是這樣能更省油！

航行的速度也是愈快愈好，因為動力裝置在趨勢上總是在流體速度愈高的環境下能夠產生愈好的堆動效率，前篇 ^[4] ^[5] 的螺旋槳分析也是從具體的動力裝置運作細節分析中得出了同樣的趨勢，在前面的遊戲中也以容易理解的方式解釋這項特性的作用原理。這就是為什麼(通常)飛機飛的快的時候反而省油錢，也是那些一般概念上效率比較差的動力裝置如渦噴發動機等，它們上了高速之後效率都有所提升，甚至可能反超一般印象中效率比較高的其它動力裝置的原因。

最後談談升溫這件事在推動裝置上扮演的角色。因為本篇所探討的是一種抽象的動力裝置而脫離了具體的實現方式，因此有些部份無法很有連結性的表達與整體性能的關聯，而溫度就是其中最模糊的成份！這是因為有些東西它與具體的實現方式牽連性太大了。比方說在未知發動機具體結構原理的情況下，我們無法知道流體在發動機裡面是怎麼被加熱的？是等壓行程還是等容行程？甚至於有沒有汽化過程參與，還是有發生化學反應(如火箭)等都不知道！唯確認的是溫度的升高肯定需要分走發動機(或燃料)所給予的能量，這就是為什麼前面計算式只假定了一個等效的比熱容，其主要的作用可能在於表示確實升溫愈多會導致效率愈低。對於大部份需要給流體升溫的發動機(渦噴、火箭等)來說，升溫的目的是給流體膨脹以增速，也就是說這類發動機是以 $\Delta T$ 為代價去換取更高的 $\Delta V$，只不過在本篇的計算中並沒有將兩者的關聯給聯繫起來，而是直接取其結果($\Delta V$)作為計算使用。其實對於所有類型的動力裝置，本篇的計算式也並沒有交代 $\Delta V$ 是怎麼產生的，而是隱藏了黑盒子內的具體的運作過程，只是將其理解為「動力裝置投入能量一番作用之後」所產生的結果來使用。因此對於溫度這一部份，我們只需理解它的存在是某些類型發動機之所以能夠產生推力的必要副作用就可以了！

以上關於排氣溫度這一特性就是對於現代渦輪風扇發動機為什麼效率比純渦輪噴射發動機更好的主流解釋方式。就是因為渦扇發動機的尾氣(假設兩路尾氣混合均勻的情況下)溫度比渦噴發動機更低，因此能得到更高的運作效率！

\[ \frac{ C \cdot \Delta T }{ \Delta V \cdot V_i } \]

其實在效率式的分母裡面關於溫度的那一個項(如上所列)也能看出來， $\Delta V$ 的增加是有利於讓這個項的值變小，從使這個部份對整體效率來說是往有利的方向發展。其本質上也是在說明，如果能夠使用愈小的 $\Delta T$ 來換得愈大的 $\Delta V$，那麼對於推進具有性能更好的貢獻。這就是為什麼火箭的燃料都傾向於選擇那些燃燒後膨脹性更好的物質的原因 (其實也未必盡是如此，因為燃料的選擇往往還得妥協很多其它方面的考量，但就性能面來說是這樣沒錯)。

最後，對於上面所提的眾多「改善方案」之外，其實還有最後一種做法，那就是放棄！如果要求改變環境流體密度不切實際，如果我的動力裝置它就是口徑小而且難以做大，如果我的航速就是沒法拉很高，甚至如果我就是得需要強烈升溫才能夠給流體加速，然後我還希望能夠保有不錯的推力，那我還有什麼辦法呢？有的，那就是放棄效率！為了得到所需要的推力，就只能使勁噴用力吹，以犧牲效率的方式去得到推力。這就是為什麼早期渦噴發動機的效率都相當破爛的關係，除了因為一些改善效率的先進技術還沒被發明應用之外，也是因為在當時的時空背景下這個推力是更加被迫切需要和追求的東西，反而效率這一部份的損失就是帶多點油給他燒就能解決的問題。同樣這也是為什麼火箭發動機的效率更加破爛到底(約只有個位數的百分比)的原因，除了狂噴猛吹之外，排氣溫度還恨不得能夠熔化世間萬物；至於其強大的推進動力則是由極高的燃料消耗速度所換來，因此雖然火箭的絕大部份質量都是燃料，卻能夠在數秒到數十秒，最多數分鐘的時間裡面消耗殆盡！

常見矛盾疑惑

相信可能許多人在讀本篇的時候會感到些疑惑，因為本篇所描述的某些部份可能和一般的經驗印象不甚相同，甚至於有些東西看起來可能和我前篇所寫的內容有相矛盾之處。那麼這些部份是怎麼一回事呢？這裡就來為這些問題做出解惑。

口徑過大時效率會下降？

首先是關於動力裝置口徑的問題。在前篇 ^[4] 的螺旋槳分析中就呈現出來，口徑愈大、轉速愈慢一般來說是效率更高沒錯，但是當口徑大過某個程度以上，或轉速慢到某個水準以後，效率反而開始下滑了。這是怎麼一回事呢？怎麼就和本篇描述的不一樣了呢？

其實那個問題是螺旋槳的問題，是因為螺旋槳本身的運作特性所導致的性能限制。螺旋槳動力裝置使用螺旋槳葉片來達到增加流體流速($\Delta V$)的效果，而其實際實現方式的運作特性導致產生了這樣的性能限制；但是如果換成使用別的原理來給流體加速(比方改用衝壓原理來加速氣流)，就不一定存在這樣的限制了，或者也許依舊存在類似的性能限制但裕值可能不同！也就是說所提出的這個疑問是屬於具體實現方案本身的特性與限制所導致，而當跳脫了具體實現細節而站在抽象的黑盒子角度來分析的時候，或者也可以理解為當站在廣泛各種動力裝置的綜合體來討論共同通性的時候，自然能夠忽略個別實做所特有的一些條件限制，因為那只是個別裝置類型自己的問題。

高航速應該比較耗油？

第二個可能的疑問是本文提到當動力裝置運作在愈高速環境的時候推力愈大、效率也愈好，可是我們一般的印象可能卻是車開的愈高速(腳踩的那種可能感受更加直接)阻力愈大，或者可能愈加使不上勁；或者我們所知到的那些能夠超高速飛行的飛機(如協合客機、或 SR-71 黑鳥等)往往也是相當耗油，燃料消耗相當可觀的。這些現象都與本文給出的分析不同，這又怎麼解釋呢？

除了前述「個別實現方式自己的特性與限制」佔一部份比例之外還有另一項因素，那就是本文所專注探討的是動力裝置本身的情境，而我們一般所感受認知的通常都是整機整體的結果。也就是說以廣泛通用的情況來說動力裝置是在愈高的航速環境下運作更有效率，但是整機的阻力和其它部位的干擾因素可能是隨著航速的增加而愈大。因此在實際的整體情況，通常各部件的推力、阻力、效率等此消彼長之下，中間通常會存在一個最佳的甜蜜點；然而在只考量推進裝置的運作效率，且撇開個別實現邏輯所帶來的各自限制之外，那確實是航速愈高的情況下其推進效率是愈高的。

飛的愈高愈省油？

還有一個與通常現象衝突的地方。本篇告訴你動力裝置在流體密度愈大的地方(在空氣中通常就是低高度的大氣)效率好，而密度低的低方(也就是高空)效率差。這時可能有許多熟悉航空的人就想要說話了：「欸不對，我們的經驗明明都是說高空效率更好……」有些人甚至會拿出真實的燃油報告來證明所言不假，飛機飛高空更省油，反而上次因為什麼緣故降低高度飛，結果油耗一下就上來，甚至不得不中轉加油等等。那麼為什麼會出現這種矛盾衝突呢？究竟是誰對誰錯了呢？

其實理論沒有錯，他們的敘述也沒有錯，因為同前面所說，實際的情況是綜和了各方各面互相影響之後的最後結果！不過就算不計算飛機的阻力因素而只看發動機推動效率，現實上往往也是高空比較節省，為什麼呢？密度高對效率有利，密度低不利；航速高對效率有利，航速低不利，這些都是確實的。也就是說一般的發動機上了高空的確會受到空氣密度下降的影響導致效率下降，但同時也會因為航速增加的影響導致效率上升，兩者互搏之後的結果是航速更勝一籌。因此造成現實中的這種經驗其實是因為飛機飛的高了，在飛行速度增加之下得到的好處勝過因為空氣密度下降的壞處，而且勝得多；然而即便是這樣現實的真實經驗，也並不能反對空氣密度降低這一條件確實是造成效率劣化的元素。其實如果能夠的話，讓飛機在接近地面的高度以超高速飛行那肯定是推進效率最好的，絕對比高空高速飛行好得多；只不過無奈現實中可能罕有飛機能夠扛得住這種條件下的壓力而不會散架，因此才不得不在低空飛的慢一點！

其它補充

其實本篇所描述的理論是建立在一個相當完美的條件之下所成立的，而現實中的動力裝置往往無法達到所假設的完美條件，因此實際的性能往往達不到本篇所計算的結果；也就是說，本篇站在抽象完美角度所得出的性能，會是實際裝置永遠達不到的天花板。

Figure 11. 螺旋槳尾流示意 ^[6]

這裡以本系列所探討的動力裝置即螺旋槳作為代表性的案例進行探討。螺旋槳在運作的過程除了推動流體向後之外，也會順帶推動流體旋轉，在螺旋槳後形成帶旋的尾流 ^[7] ，如上圖(Figure 11)所示。經過螺旋槳後出來的氣流是 $V_s$ 其可被分為兩個分量分別是 $V_x$ 和 $V_\theta$。那麼我們就知道對於推進有所作用的只有其中的 $V_x$，所以在算推力的時候就要使用 $V_x$ 來算，而另一個分量 $V_\theta$ 並沒有作用；但是在計算需要投入多少功率來驅動空氣的時候卻要使用 $V_s$，即便那些不在推力線上的速度分量沒有作用，但是卻實打實的吃掉了發動機功率。這就是為什麼螺旋槳產生的旋轉尾流會導致推進效率劣化的原因，也是為什麼但凡能夠偏導校正螺旋槳旋轉尾流的設計能夠立刻改善推進效率的原因。

總結

本篇介紹了更加單純簡單的方式去理解推力裝置，除了更加容易理解和計算以外，這種分析方式還並不只能被套用在螺旋槳上，還能套用在渦噴、渦扇、火箭、……等等等，凡任何透過流體反作用力產生推力的系統都能使用本篇所介紹的方法來理解與估算。在跳脫細節對認知的束縛之後，我們更能夠從更高的層面去理解流體動力裝置的特性，並得到一些與性能息息相關的影響參數，當流體密度更大、裝置口徑更大、或航速更快的時候，可以得到更多的推力和效率；而增加流體吞吐速度差的話可以提高推力但會損失效率；此外也認識到了流體溫度的增溫在宏觀抽象層面上對推動效率的影響。

1. Exercise ball

2. 推車

3. 活塞引擎 7：功率與效率

4. 螺旋槳 8：該有幾片槳葉？該造多大？

5. 螺旋槳 7：性能分析案例

6. Blade Element Theory for Propellers

7. 螺旋槳 3：各種奇妙問題

螺旋槳 8：該有幾片槳葉？該造多大？

Fri, 24 Oct 2025 10:27:16 +0800

在我們見過的那些螺旋槳飛機裡面，有的飛機螺旋槳只有兩葉，有的三葉、有的四葉，還有的更多，五花八門。那麼槳葉的數量是怎麼決定的呢？難道是靠美感嗎？甚至於，有些飛機的螺旋槳相當巨大，有些飛機的螺旋槳看起來小得多，那麼又是哪些因素造成這些差別呢？本篇就要來探討這些不同槳葉數量和尺寸大小對於螺旋槳性能的影響。

計算模型

本篇仍舊使用前篇 ^[1] 使用過的計算程式，並稍做修改 ^[2] 以計算與比較本篇不同構型螺旋槳的性能。並且本篇所使用的幾個分析案例也衍伸修改自前篇所使用的橢圓形槳葉案例，只不過為了方便在槳葉的參數上做些文章，因此對於槳葉的造型做了點變化，成為下圖(Figure 1)所示的樣子。其性能表現結果與前篇原版的橢圓槳葉螺旋槳相近但仍有所差異，因此不建議將前後篇的性能表現互相比較。

Figure 1. 本篇分析所使用的基礎螺旋槳造型

另外本篇在性能圖表的表現方式上也有所更動。由於前篇算是對螺旋槳分析的介紹和了解，因此對螺旋槳性能的細節描述比較詳細，而本篇圖表將不會過份強調在細節上，而是將更加看重整體的表現結果。首先要排除的就是螺旋槳的 K 值，也就是無因次化之後的槳距。之前我們能在同一張圖表上看到各種不同 K 值螺旋槳的性能變化趨勢，但是現在我們要假設這是一個可以自由變距的螺旋槳，並且在測試的過程中存在一個虛擬的駕駛員，他會隨時調整螺旋槳的槳距，將螺旋槳盡可能的保持在最高效的位置。以下圖(Figure 2)為例，意思等同於我計算出無限多組不同 K 值之下的結果，並取它們各自的效率最高點連線起來，就成為一個只有 J 值(無因次的航速與轉速比例關係)和效率對應關係的圖表，而其中每一個位置的 K 值可能都是不同的。

Figure 2. 排除 K 值(或可理解為自動化 K 值)後的螺旋槳性能圖表示意

那麼按照上述的處理方式將本篇所使用的螺旋槳進行計算分析，其之速度比例與效率之間的變化關係就會如下圖(Figure 3)所示，而速度比例與推力係數的變化關係就如下圖(Figure 4)所示。可以看出在 J < 1 的時候效率會隨著 J 值的增加而快速增加，表現基本與前一張圖(Figure 2)一致。但是在大約 J > 1.5 之後效率的表現基本就持平，在大約 J = 2 的時候達到最大值，之後便緩步稍降。至於推力的表現與 J 值之間基本就是線性變化關係，因此在分析計算中如果為了簡化算式的話，也可以用直線去作推算近似。

為什麼 J 值大道某一個程度之後螺旋槳效率反而會(微幅)下降呢？因為這時候的螺旋槳已經轉的太慢了！ J 值就是航速與轉速的比例關係，因此在 J 過高的情況下就表示轉速是相當低的(畢竟航速最大也不會達到音速)。而槳葉本身本來就具有阻力，就算螺旋槳完全不轉動也仍然會有一定的基礎阻力。意思就是說，當 J 值高到某個程度以上的時候，因為螺旋槳轉速過低，產生的推力已經非常微小，使得在這個情況下槳葉本身的阻力在整體螺旋槳表現之中的佔比會開始被拉高凸顯出來。於是就造成了產生的推力微小，雖然所需要的轉動功耗也是相當微小，但是因為基礎阻力的影響比重被拉高，因此反而造成最終效率下降的結果。不過另外一個現象也值得注意，那就是即便在 J 過高時候的效率已經不及全局最佳效率值，但是仍然是處在高檔位的區間！從下圖(Figure 3)來看 J = 4 時的效率雖已不及 J = 2 時的最大效率，但仍是屬於高效率的區段！

Figure 3. 本篇所使用之基礎螺旋槳的效率變化圖

Figure 4. 本篇所使用之基礎螺旋槳的推力變化圖

槳葉數量與寬度的影響

我們前篇所分析的螺旋槳都是兩葉的，那麼採用不同的槳葉數量會有什麼不一樣呢？與此類似的延伸問題還有，採用不同寬度的槳葉又會有什麼不同的表現呢？為了實驗這些問題，本篇在前面設計的基礎造型之下衍伸出幾個不同造型的螺旋槳用來計算並比對。如下圖(Figure 5)所示，兩個螺旋槳造型與本篇所使用之基礎螺旋槳完全一樣，除了槳葉數量分別增加為雙倍和四倍；而下圖(Figure 6)所示則為在槳葉的寬度上做變化。這兩種螺旋槳的變化都達到了增加槳葉總面積的結果，其增加的槳葉面積也完全相同，只不過前者是採用增多槳葉數量的方式，而後者是採用槳葉加寬的方式達成。

Figure 5. 在槳葉數量上變化：左為四葉螺旋槳、右為八葉螺旋槳

Figure 6. 在槳葉寬度上變化：左為雙倍寬度槳葉、右為四倍寬度槳葉

Figure 7. 幾種不同造型螺旋槳的推力表現圖

Figure 8. 幾種不同造型螺旋槳的效率表現圖

按照前章節描述的方式將這幾種不同造型螺旋槳的性能都計算出來後，結果就如上圖所示(Figure 7 與 Figure 8)。其中最直觀的就是推力係數直接的倍比增加了！這很容易理解，因為不論是增加槳葉數量或是增加槳葉寬度，都是實質上的增加了螺旋槳的槳葉面積，因此推力成比例上漲就是意料之中的結果，並且它們各自的推力變化趨勢也大致仍是線性的。只不過呢，從圖表中也同樣看出來螺旋槳推力的增加並不是完全的兩倍或四倍。我們就取在 J = 2 時的數字(如下表 Table 1)作為比較。先看增加槳葉數量的案例(就是標示為 double/quad blade number 的案例)，槳葉的數量加倍後，推力係數與原來加倍前的數字相比也幾乎增加為兩倍，只不過數字略小於兩倍，而當槳葉數量再加倍時也同樣如此。再看增加槳葉寬度的結果(就是標示為 double/quad blade width 的案例)也相同，推力也是略小於原有基礎造型的加倍並且略小；只不過這個「略小」比起前面增加槳葉數量的方式來說又略小的更多了！

那麼明明槳葉面積增加了，為什麼推力沒有等比例加倍呢？為什麼推力會「略小」呢？這顯然就是當中存在一些損耗了！因此我們再看看這幾個螺旋槳在效率上的數值差異(Figure 8 與 Table 1)將會更加明顯。我們使用作為比對的基礎螺旋槳在 J = 2 時有著 93.22% 的效率，而將槳葉加倍之後，效率就下降到了 91.82%，再加倍則繼續下降到 89.79%；增加槳葉寬度的方案基本趨勢是一樣的，但是效率損耗的更多！當槳葉加寬為雙倍之後，效率下降到 90.92%，再加寬則降到 87.72%。如果有讀者覺得這些數字看起來都很高很優秀，覺得下降的也不多啊！那麼我們就把前篇那個竹蜻蜓式螺旋槳也拿來比較一下，那個效能上一般會被嫌棄到爆炸的竹蜻蜓螺旋槳，它在 J = 2 的時候效率都還有個 76.09% 喔！如果這樣一對比的話，你看這不管是增加槳葉數量還是增加槳葉寬度的方案，雖然表現仍舊比竹蜻蜓螺旋槳好得多，但已經不再是可以忽視的性能劣化了吧？！

Table 1. 取在 J = 2 時，各螺旋槳造型的性能結果列表
案例	J	K	$C_{thrust}$	$\eta$
Original	1.99	2.16	0.044033	93.22%
Double blades	1.99	2.13	0.072354	91.82%
Quad blades	1.99	2.11	0.114512	89.79%
Double width	1.99	2.12	0.064664	90.92%
Quad width	1.99	2.10	0.092042	87.72%
Bambo-Copter	1.99	3.35	0.136954	76.09%

螺旋槳的槳葉總面積增加了，但是整體效率卻劣化了，這其中的損失主要就來自於槳葉尖端所造成的誘導氣流。不論是螺旋槳的槳葉還是飛機的機翼，這個翼尖的誘導渦旋愈強愈大的話，對翼面性能的劣化會愈嚴重，因而衍生的許多翼尖設計以及機翼造型都是為了減小翼尖渦流所帶來的影響。在螺旋槳上面，每一片槳葉同樣會受到槳葉尖端的誘導渦旋帶來的影響導致性能劣化，並且並不僅止於受到槳葉自己的誘導渦旋影響，其它槳葉所造成的誘導渦旋同樣影響著螺旋槳上的每一片槳葉，每一片槳葉所受到的都是全部槳葉所帶來的誘導氣流疊加的結果。因此就不難理解為什麼槳葉數量愈多之後，螺旋槳的效率就愈低了，因為當槳葉的數量愈多的時候，槳葉與槳葉之間的距離靠得更近，彼此互相影響的效果也就愈加顯著！

若不增加槳葉數量，而改以增加槳葉寬度的方式來增加槳葉總面積，同樣也遭遇了效率下降的結果，其原因同樣也來自於誘導氣流！雖然槳葉的數量一直維持在兩葉而無增加，但是槳葉寬度增加的結果同樣也會導致翼尖誘導渦旋被加強的結果；並且雪上加霜的是，槳葉寬度的增加還導致槳葉的展弦比降低了，這又會進一步導致受到誘導氣流的影響加劇。或者其實也可以理解為，將葉寬度增加一倍的方式其實相似於前面增加螺旋槳數量的方案，只不過槳葉兩兩一前一後的靠在一起，那麼因為槳葉之間距離更近的關係，彼此的影響效果自然又放大了。從實驗結果來看，增加槳葉寬度的做法帶來的性能劣化都大於增加槳葉數量的做法，這就說明了為什麼我們眼界所及的飛機較少會在寬度等造型上去變化，而是大部份以增減槳葉數量來處理的原因了！

槳盤尺寸的影響

除了造型的不同之外，螺旋槳常常也是有大有小，那麼不同大小的螺旋槳之間又有什麼樣的差異呢？

首先來談談螺旋槳的性能瓶頸！螺旋槳的轉速並不能夠無限制增加，其性能實際上會受到空氣音速的限制。當某個地方的速度達到音速的時候，就會開始出現超音速流場所特有的「震波」問題，這會導致螺旋槳的扭矩突然增大，以至於即便投入更高的驅動功率卻難以再增加更多推力的結果。那麼螺旋槳的哪裡會遭遇到最大的氣流速度呢？顯然就是在槳葉的尖端了！因此我們可以將螺旋槳的尖端速度設定為一個固定的數字，而在此條件之下的螺旋槳效能大約就是能夠產生最大推力的狀態。

Tip	其實從這裡就已經可以知道，螺旋槳的轉速受到音速的限制，槳葉尖端速度最大值差不多就在音速附近，考量此時還必須保有一定前進氣流的情況，實際轉速還會再更低。這就是為什麼採用螺旋槳作為動力的飛機肯定只能在音速以下飛行的原因！對照現實，二戰末期的螺旋槳飛機極速約在 750 km/h 上下，而萬米高空的音速約為 1080 km/h，因此螺旋槳飛機的極限航速大約為接近 0.7 馬赫的速度。

Figure 9. 槳葉氣流的組成

如同上圖(Figure 9)所示，螺旋槳葉片上某個位置的氣流速度會受到槳葉自身的旋轉運動、以及自由氣流兩者的合成 (為了簡化分析，誘導流的存在就先不考慮了)。於是這裡假設螺旋槳尖端的氣流速度 $V_{b_{tip}}$ 為：

\[ V_{b_{tip}} = \sqrt{ V_\infty^2 + \left( \frac{D_p}{2} \omega \right)^2 } = V_{sound} \]

其中 $V_{sound}$ 為音速，而其它相關符號定義請參閱前篇 ^[3] 。

由於我們這次的比較重點放在槳盤大小造成的影響差異，因此就假設其它條件不變，也就是說在同樣的音速和同樣的航速下進行比較。那麼上式就能整理為：

\[ D_p \omega = 2 \sqrt{ V_{sound}^2 - V_\infty^2 } = Const. \]

然後我們假設有兩個除了尺寸不一樣以外其它參數完全一模一樣的螺旋槳，一個螺旋槳槳盤直徑為 $D_{p1}$，其最大轉速為 $\omega_1$，另一個螺旋槳的直徑和最大轉速則分別為 $D_{p2}$ 和 $\omega_2$。再假設其中第二個螺旋槳的槳盤直徑為第一個螺旋槳的 $\gamma$ 倍，那麼：

\[ D_{p2} = \gamma D_{p1} \] \[ D_{p2} \omega_2 = Const. = D_{p1} \omega_1 \] \[ \gamma D_{p1} \omega_2 = D_{p1} \omega_1 \] \[ \omega_2 = \frac{\omega_1}{\gamma} \]

接著就能發現一件事，無論槳盤尺寸如何放大縮小，在最大推力的條件下 J 其實是不會改變的！如下：

\[ J_2 = \frac{ 2 \pi }{\omega_2} \frac{V_\infty}{D_{p2}} \] \[ = \frac{ 2 \pi \gamma }{\omega_1} \frac{V_\infty}{ \gamma D_{p1} } \] \[ = \frac{ 2 \pi }{\omega_1} \frac{V_\infty}{D_{p1}} \] \[ = J_1 \] \[ J_2 = J_1 = J \]

在最大推力條件下無論槳盤尺寸如何，J 直都是一樣的，自然的我們的虛擬自動駕駛員給它調整後的 K 值也會是一樣的；這就表示連同其它所有相關係數都會是一樣的，因此我們無需再做其它分別處理。那麼我們就能夠計算兩副螺旋槳的推力：

\[ Thrust_2 = \rho \left( \frac{\omega_2}{ 2 \pi } \right)^2 D_{p2}^4 C_{thrust} \] \[ = \rho \left( \frac{\omega_1}{ 2 \pi \gamma } \right)^2 ( \gamma D_{p1} )^4 C_{thrust} \] \[ = \gamma^2 \rho \left( \frac{\omega_1}{ 2 \pi } \right)^2 D_{p1}^4 C_{thrust} \] \[ = \gamma^2 \cdot Thrust_1 \]

至此我們已經得到結果。不同尺寸的螺旋槳(在輸出最大推力的前提下)所有係數都是相同的，也就是說性能特性與效率等都是相同的，只不過轉速會與尺寸倍率成反比，而推力會與尺寸倍率的平方成正比(其實也就是與槳盤面積成正比)。也就是說，當槳盤直徑增加為兩倍時，最大推力會增加為原有的四倍；反方向也可說，當槳盤直徑縮減為一半時，最大推力會減少至原有的四分之一。因此在應用上，螺旋槳的尺寸不能夠小於某個數值，否則它可能會在死命賣力的極限運轉下都無法提供你要的最低推力 (當然這是在不改變其它設計參數而只改變尺寸的情況下)！這也是為什麼直升機的螺旋槳(旋翼)必須造的那麼大的原因！

不同尺寸在等推力需求下的差異

前面探討了不同尺寸螺旋槳的性能差異，但是重點放在了極限性能的表現上；而本節一樣要探討螺旋槳尺寸差異造成的影響，只是將條件改變為在提供同樣推力輸出的水準下。這樣做的意義是什麼呢？比方說我們想要設計或改裝一架飛機，這時候飛機的推力需求以及飛行條件如空速等就是不變的，可能再強力的推力裝置也得給我們減小油門才不會讓飛機散架。於是這就符合了本節所要討論的場景：在提供相同推力的前提下，比較不同尺寸螺旋槳的影響差異。

其實從前面的分析結果已經可以得到關於本節關注重點下的一些有用訊息：尺寸更大的螺旋槳能夠提供更大的推力，我們可以讓螺旋槳放鬆一點不用轉的那麼賣力，就能得到所需要的推力；而尺寸更小的螺旋槳提供的推力比較小，會需要更加賣力的飛速運轉才能夠提供所需要的推力 (當然是在有餘裕能夠轉的更快的前提下)。由於在這樣的情況下，我們會需要手動為不同的測案調整變更轉速，以得到所設定的推力，那麼 J 值和 K 值都會有所變化，連帶的所有性能相關係數也都會不一樣，因此不再能夠像前面的分析一樣輕易的從數學式就能推導出結果關係。所以這裡就直接挑選了幾個不同的螺旋槳尺寸去調整並計算性能。螺旋槳的參數採用前面作為測試比較基礎的橢圓雙葉螺旋槳，只改變其槳盤尺寸。不同槳盤尺寸的計算結果數據如下表(Table 2)，而其所使用的一些共同條件參數則如下所列：

\[ \rho = 1.225 \] \[ V_\infty = 83.33 \]

Table 2. 在同樣推力的運作條件下，幾種不同尺寸螺旋槳的表現比較
$D_p$	$\omega$	J	K	$C_{thrust}$	Thrust	Efficiency
1.0	1179.0	0.444	0.500	0.024532	1058.125	82.10%
1.5	489.6	0.713	0.780	0.028100	1058.109	88.52%
2.0	261.0	1.003	1.080	0.031286	1058.102	91.28%
3.0	102.8	1.698	1.820	0.039841	1058.225	93.14%
4.0	50.3	2.602	2.830	0.052652	1058.199	92.91%

計算的結果與前面的預期相同，當螺旋槳愈大的時候，轉速就可以放的愈慢，這會讓 J 值增加，而較大的 J 值造成的最主要差異在於效率上。也就是說至此已經可以整理出一個結論：在給定推力需求的條件下，選用尺寸愈大的螺旋槳則效率愈佳；在不考慮其它比方說結構負荷與平衡性等等條件的情況下，理論上盡可能選用更大的螺旋槳是更加有利的！即便在上面的測試案例裡，那個尺寸最大的螺旋槳效能其實已經過了最高峰在往下走了，但是效能也依然是處在最高段位的區間！

Note	上面表格(Table 2)裡各案例是我手動調試參數計算的，所以數字不會那麼完美相同，不過它們之間的推力相差都在千分之一以下，基本可以算做是推力相同了！另外，這些案例都忽略了音速造成的限制，也就是轉速無上限，否則若不做這樣放寬的話，有些小螺旋槳可能怎樣也無法產生額定的推力！

選擇裝配螺旋槳

介紹完螺旋槳的幾個主要參數和性能特性之後，現在讓我們站在設計飛機的角度要給自己的飛機挑選安裝螺旋槳，要怎麼決定這些參數呢？

尺寸大小

首先就是尺寸要儘量大，在能夠負擔的程度裡面愈大愈好！在前面的分析結論裡已經知道，當推力的需求下限定出來之後，螺旋槳的最小尺寸就已經決定了，因為更小的螺旋槳是怎樣也達不到所需要的推力的！ (當然也可以多配幾個螺旋槳等等，這裡暫不探討這些變因)

尺寸的下限決定了，那麼上限呢？在前面的分析圖表裡都能看得出來，站在推力與效率等性能角度來看，更大的螺旋槳能夠帶來更大的推力上限，並且效率還更好。當然也許有些讀著會說「且慢！」前面不是才從圖表中看到，當螺旋槳尺寸過大到超過額定需求太多時，效率反而不是最好而是微幅下降嗎？事是這樣沒錯，但是通常來說並不需要去擔心這個問題！因為後面我們馬上就會知道有許多其它的因素會限制你的螺旋槳大小，也並不是想要大就能夠無限制的大；即便真的讓你大到些許超過實際的需求了，從圖表也能看出螺旋槳的效率降低程度也僅只是稍微下降而已。因此總結下來，絕大部份的情況下就是在條件許可的範圍內選用盡可能大的螺旋槳就行了！

那麼有哪些現實的因素會導致螺旋槳的尺寸受限呢？首先就是飛機的體量了！用白話來說就是螺旋槳太大的時候會超出你飛機的掌握能力之外。舉個誇張的例子，假設你有一架機身長度和機翼寬度大約在 5 公尺左右的飛機，然後這飛機配了個直徑 20 公尺的螺旋槳，那麼請問到時候是飛機控著螺旋槳在轉呢？還是螺旋槳在控著飛機轉呢？！螺旋槳的尺寸愈大時，其所產生的一些奇妙的問題 ^[4] 也會變得更加明顯突出並且更難以掌控應對。因此雖然理論上螺旋槳是更大點更好，但是飛機本身的體型其實會很自然的限制住你的螺旋槳尺寸；如果硬要裝配個超出正常體量範圍的超大螺旋槳，那麼你的飛機很可能會先被螺旋槳產生的那些如反扭矩等問題給鬧個半死！這時候有些人也許會舉出手指來指著直昇機欲言又止。是的，直昇機的大螺旋槳(旋翼)確實超出它機體的體型所正常能夠負擔的尺度，所以直昇機的控制更加複雜且困難，光是為了應付巨大旋翼所產生的反扭矩，就造成了那成為了直昇機標誌性特色的尾旋翼。

第二個限制螺旋槳尺寸的因素則是起落架的長度。除非你的螺旋槳是像直昇機那樣躺著的，否則在常規的設計下往往必須要考慮在正常起降和地面停放的時候能讓螺旋槳懸空不觸地，使得在中小型的飛機上面，這點要求可能會成為限制住螺旋槳尺寸的主要困難之處！

Figure 10. 比機身的尺寸更加巨大的主旋翼搭配一個用來平衡扭矩的小尾旋翼，幾乎已經成了所有直昇機的共同特徵 ^[5]

Figure 11. 為了將直徑達 3.4 公尺的螺旋槳架離地面，J7W1 震電戰鬥機的起落架造的特別長！ ^[6]

Figure 12. F4U 海盜戰鬥機標誌性的逆海鷗翼設計，就是為了在不特別加長起落架的情況下將那直徑達 4 公尺的巨大螺旋槳架離地面而存在 ^[7]

槳葉數量

選擇槳葉的數量大概是在搞定尺寸問題之後的第二項任務了吧！經過前面的分析比對，我們知道槳葉的數量那是愈少愈好，所以在沒有其它特別考量的情況下一般就是直接選用二葉螺旋槳即可。事實上要不是因為力平衡和振動的問題無解，否則單葉螺旋槳一定會變成效率最高的選擇！

既然雙葉就是能夠取得最佳效率的葉片數量，那為什麼還有那麼多飛機會使用更多葉的螺旋槳呢？這就要提到驅動螺旋槳的發動機的動力上面了！當發動機的動力超過螺旋槳所能夠消耗應付程度的時候，多出的發動機功率就會面臨無用武之地的尷尬！怎麼說呢？和發動機的功率上限是相似的道理。螺旋槳就是將旋轉的驅動力轉化為向後推動空氣的作用力的裝置，所以它若能夠吃下更多的驅動力，就能夠轉換出更多的後吹驅動力；但是這個驅動力是不是存在一個上限呢？是不是即便驅動的動力來源其實動力充沛但螺旋槳沒法吃下更多的軸功呢？這個問題是肯定的，並且本篇以及前篇 ^[1] 所分析的計算結果都已經再再顯示出這項限制。當驅動的動力來源不斷加強的時候，我們的螺旋槳並不能夠無限制的提高槳葉攻角，畢竟槳葉也是會失速的；而提高轉速最多也就是在葉尖出現震波的時候就達到極限了。當然我們可以安裝上更大號的螺旋槳來消耗軸功並產生更大的推進力，然而如前面段落所述，只寸往往已經被限制住了！

於是當發動機的功率足夠強勁時，為了在有限的尺寸大小內能夠吃下更多的發動機功率，這時就會需要為螺旋槳增加槳葉的數量，即便這麼做是以損失螺旋槳的推進效率作為代價的；但如同從前我所說過的，效率與功率本就常是相背的兩項屬性 ^[8] 。當然增加槳葉的面積也可以達到同樣的效果，但如同前面的分析結果那樣，將槳葉加寬的效果更劣於增加槳葉數量的方法，因此實際上都還是以增加槳葉的數量來作為應對裝配更高功率發動機時的手段。這就是我們看到的那些飛機為什麼會裝配更多葉螺旋槳的主要原因了！於是當看見採用螺旋槳飛機採用的葉片數量時，基本大致就能知道它的發動機功率在什麼樣的等級。以使用活塞發動機的情況來說，每一副螺旋槳的葉片數量大多都在雙葉到 4 葉，部份使用更大功率發動機的飛機可以用上 5 葉到 6 葉螺旋槳，至於再更多的就罕見了；而採用渦輪發動機的螺旋槳飛機，因為功率更加充沛的緣故，槳葉數量甚至可達 8 葉或更多。

不過槳葉的葉片數量也並不是這麼死板而缺少彈性的，並不是說計算下來應該對應 3 葉螺旋槳的情況就不能夠使用 2 葉或 4 葉；只要不是跨度太大，比方說計算下來應採用 3 葉，結果你放了個 8 葉螺旋槳(反之亦同)，那麼基本不至於會有什麼太大的問題。所以實際上其實也有不少飛機基於其它因素的考量而稍微調整變更螺旋槳的槳葉數量，其中最常見的因素就是因為振動的關係了！比方說著名的零式戰鬥機在設計之初所採用的便是雙葉螺旋槳，結果在後來的試飛過程發現難纏的共振問題，最後是換用 3 葉螺旋槳避開這個共振來解決這個問題！

Figure 13. 採用雙葉螺旋槳的 Cessna-172 小飛機 ^[9]

Figure 14. 採用 3 葉螺旋槳的 P-40 戰鬥機 ^[10]

Figure 15. 採用 4 葉螺旋槳的 P-51 戰鬥機 ^[11]

Figure 16. 噴火戰鬥機跟著不斷換裝更強力發動機的型號進程，槳葉數量也從 2 葉開始不斷增加，圖中則為採用 5 葉螺旋槳的 Mk XVI 子型 ^[12]

Figure 17. 採用 6 葉螺旋槳的 J7W1 戰鬥機 ^[6]

Figure 18. 原採用 2 葉，後因振動問題而改用 3 葉螺旋槳的零式戰鬥機 ^[13]

Figure 19. 採用多達 8 葉螺旋槳的 C-130H 運輸機 ^[14]

總結

本篇延續前篇的螺旋槳性能分析，繼續分析了有關螺旋槳尺寸大小、槳葉數量、以及槳葉寬度等參數對於整體性能的表現差異。其中螺旋槳的轉速愈低則大致上整體效率愈高，只不過轉速過份低的時候可能會導致效率微幅下降的反效果；而螺旋槳所能產生的推力大小則主要決定於槳盤面積以及槳葉數量。若是站在追求效率與動力的角度，則得出應在所能夠負擔的範圍內採用最大尺寸的螺旋槳為佳的結論；而在尺寸已定的前提下若發動機功率過剩，則可以增加槳葉數量的方式，透過效率的犧牲下降來換取能夠完整發揮發動機功率的性能空間。

最後，本篇所使用的螺旋槳分析程式以及計算結果等資料，都在此提供下載 ^[15] 。

螺旋槳 7：性能分析案例

Mon, 13 Oct 2025 23:41:24 +0800

繼前篇 ^[1] 介紹了螺旋槳分析的計算後，本篇要來挑幾個分析案例，給我們展示一些螺旋槳的性能表現和特性。

竹蜻蜓式螺旋槳

Figure 1. 簡單平直且無扭轉槳葉的單純雙葉螺旋槳

第一個案例就先選擇一個最單純的，最簡單的外型，長相就像上圖(Figure 1)那樣。這副螺旋槳有兩片槳葉，葉寬(也就是翼弦長)從頭到尾是一樣的，葉片就是一個簡單的矩型，並且槳葉從頭到尾的安裝角(扭轉角、裝置角)也是一致的，實際上這其實就是常見的玩具竹蜻蜓的槳葉造型。其中心的槳轂區直徑為整副螺旋槳直徑的十分之一(後面其它案例也與此相同)，並且槳葉使用的剖面翼型就是前篇所描述的那個翼型 ^[1] (後面其它案例也與此相同)。

Figure 2. 槳葉上的各種相關角度之分佈(J = 0.1)

上面這張圖(Figure 2)是槳葉上有關幾個「角度」的關係圖。橫座標是半徑，範圍從 0.1 到 1，就是從槳轂到槳尖。藍色那條線段就是槳葉的安裝角(扭轉角、pitch)分佈，因為這是一隻竹蜻蜓構型的螺旋槳，所以這個角度從頭到尾是一樣的。上面標註了 K = 0.5，此為這副螺旋槳的無因次槳距參數 (相關符號與意義請參閱前篇 ^[1])，但是這是一隻安置角固定的螺旋槳，因為槳葉在不同半徑位置的移動速度不一樣，所以移動距離也不一樣，意思就是實際上整片槳葉在每個半徑位置的槳距其實是不同的。因此我選擇了在槳葉半徑 R = 0.8 的那個位置的槳距作為整副螺旋槳的代表性槳距；至於為什麼選這個參數？看這張圖的分佈情況應該就能明白了！另一個參數 J = 0.1 表示這隻螺旋槳所受的前進氣流非常低，或者是航速可能並不慢但螺旋槳的轉速非常高，以至於使前進氣流的佔比非常低；如同前篇的描述，無因次化的 J 參數並不代表實際的速度大小，而是表示空速與轉速之間的比例關係。

因為槳角是固定的，所以圖上的藍線(Pitch ($\beta$))就是一條平直線。由前進氣流與螺旋槳轉速所造成的氣流角度(圖中的橙線 E_uniform ($\varepsilon_\infty$)) 也如預期一般往槳葉根部的地方逐漸變大。誘導氣流所產生的誘導角(圖中的綠線 E_induced ($\varepsilon_i$)) 則在槳葉尖端影響最大(畢竟渦流的中心就在槳葉尖端)，而愈往槳葉根部則影響愈少。最後這些因素綜合起來的槳葉攻角(圖中的紅線 AOA ($\alpha$))從根部往外圍逐漸變大，直到約在 R = 0.8 的位置達到最大值，隨後在槳葉尖端區域直線下跌。因此大約可以判斷，整片槳葉產生有效作用的主要區域應再 R = 0.5 ~ 0.9 的位置，到了槳葉尖端效率突降，至於在靠近根部的地方則因為旋轉移動速度偏低的緣故，參與的作用佔比較低。

Tip	雖然在做數學式計算的時候通常習慣使用許多希臘字母符號，但是因為在電腦圖表、以及程式寫作方面可能存在一些所使用文字的限制，因此不得不採用一些簡單的名稱去對應數學式裡的符號。這會造成在本篇以計算與圖表為主的情況下所看到的各項名稱，可能與前篇以數學分析為主所採用的希臘符號有所不同。為此本篇會盡可能在提及部份名稱的時候標註該名稱與前篇所採用符號的對應關係。

Figure 3. 槳葉上的各種相關角度之分佈(J = 0.4)

當 J 值來到 0.4 的時候，也就是在有了相當比例的空速，或者在同樣空速下當轉速下降到某個程度的時候，情況變成像上圖(Figure 3)這樣。扭轉角當然還是一樣的一條線不變，由前進氣流與轉速所造成的氣流角度變化趨勢也相同。然而因為前進氣流過大、又葉片根部區域轉速過慢，可以看到合成的最終氣流攻角在槳葉根部那一半的區域(R < 0.5)都是負的。意思就是說，該區域在此情況下非但不能產生推力，還因為前進氣流的推動而產生阻力。

Figure 4. 槳葉上的受力分佈(J = 0.1)

看完氣流角度後來看看槳葉所產生的力分佈(Figure 4)。整個分佈的情況基本單調並且與前面的圖表結果預期相符，大約在 R = 0.6 ~ 0.9 的位置承擔了幾乎大半的推力與扭矩的成份。

上面只挑了一些比較代表性的圖表讓我們細細觀察在槳葉上的分佈，接下來讓我們將視角擴大，看一看整副螺旋槳整體，在不同槳距和速度配比之下的性能表現。

Figure 5. 螺旋槳推力趨勢圖

上圖(Figure 5)繪製了幾個不同槳距(不同 K 值)螺旋槳在不同速度配比(不同 J 值)下的變化曲線。絕大部份情況下螺旋槳在航速愈高的時候(或者說轉速愈慢時)所產生的推力愈低。這很符合預期，也符合我們日常生活的經驗，即便我們平常人開不了螺旋槳的交通工具，在地上開車或騎腳踏車的我們也知道速度愈快的時候要升檔，否則固定檔位的話會在速度愈快的時候愈沒力！比較特別的是看到褐色的那條線，因為槳距高到了某一個程度，因此當航速過低或轉速過高的時候推力反而下降；這與我們的日常經驗也符合，過高的檔位在過低速時反而沒力；回到螺旋槳來看的話那就是因為槳葉扭轉的角度大了，在沒有足夠空速的情況下會導致攻角過大，並不能產生更多升力。

Figure 6. 螺旋槳功耗趨勢圖

上圖(Figure 6)為螺旋槳功耗曲線圖，注意不是扭力而是功耗，也就是需要消耗的發動機功率。我們能發現不只隨著空速比例(J)愈高時推力會愈低，連功耗也會降低。這是因為氣流的整體攻角會因為被航速給吹著而越發接近槳葉本身的裝置角，導致功耗反而降低了；甚至於當航速繼續拉高的話，攻角還會整片變負的，功耗也會是負的，因為這時反而是航速在推著螺旋槳轉，螺旋槳實際變成一個風車了，不只不消耗功率反而還能產生功率。另一個現象是褐色(K = 1.4)和紫色(K = 1.2)的左側段還表現出功耗突然拉高的情況，這就是因為裝置角大，所以在航速低或轉速高的時候氣流攻角過大，有發生氣流分離的現象，所以導致的扭矩突升現象；因此高檔位在低航速下不只不能產生多大的推力，還特別吃發動機功率！

Figure 7. 螺旋槳效率趨勢圖

上圖(Figure 7)是螺旋槳的效率分佈圖。綜和前面所閱讀的分析結果，應該已經大概能夠預期到上圖的結果了，每一個槳距配置下都有一個最適合的轉速配比可以達到最佳的效率，並且在航速佔比愈高的時候需要愈大的槳距才能產生最佳的效率。此外還注意到，雖然不同槳距都有各自最高的效率狀態，但是整體而言 J 值愈高是效率愈高的；也就是說在航速愈高而螺旋槳轉速愈低的狀態下，產生的推進效率愈高！ (這個結論是非常合理的，但可能並不符合航空愛好者或軍武愛好著的直覺印象， 那是因為這個結論只單單站在螺旋槳的推動效率來看的結果(並且還並未考慮音速這項要素)， 而實際上整架飛機的表現則需要綜合各零件與條件綜合之下的整體結果所致。)

扭轉的橢圓槳葉螺旋槳

板板直直如同竹蜻蜓樣的槳葉雖然簡單廉價，但性能上存在兩大問題點。首先是槳葉各處的氣流攻角變動範圍太大，這點在前面繪製的圖形裡都能夠看出來。因為槳葉的圓周運動中內圈和外圈的移動速度差異過大，導致槳葉根部到尖端的氣流攻角變化量過大，一邊可能還攻角太低達不到最佳效果，另一邊卻已經發生失速了！要解決這個問題，我們就需要把槳葉給扭一下，目的就是為了平衡槳葉的氣流攻角分佈，儘量使氣流攻角在整片槳葉上都接近一致而不要差異過大。另一個問題就與一般飛機機翼一樣，是來自於葉尖渦流產生的誘導氣流，而解決方法也與一般機翼的處理對策差不多，就是將槳葉形狀改為漸縮的造型。那麼基於這兩點的改進就是本篇的第二個案例了。

Figure 8. 帶扭轉的橢圓造型槳葉螺旋槳

這個案例將槳葉做成橢圓的形狀，如上圖(Figure 8)所示。並且槳葉本身也做了扭轉的設計，即槳葉上每個剖面位置的安裝角(Pitch ($\beta$))是不一樣的，只不過這個扭轉的狀態沒法從上圖展示出來。槳葉的扭轉方式存在多種方案，而本例則採用恆定槳距(Constant Pitch)的方案。恆定槳距的意思就是槳葉每個位置的槳距是相同的，並且注意這裡表達的是槳距(Pitch Length ($\lambda$))，而不是槳角(Pitch Angle ($\beta$))。也因為槳距是一致的，這順便解決了上一個案例中的一個小問題，就是在槳葉各處槳距不同的情況下究竟要以哪個數值作為整片槳葉的代表性槳距這件事！那麼在這樣的扭轉設定之下，槳葉隨意一處剖面位置的翼型裝置角 $\beta_r$ 即為：

\[ \beta_r = \tan^{-1}(\frac{\lambda}{ 2 \pi r }) \] \[ \beta_r = \tan^{-1}(\frac{ D_p K }{ 2 \pi r }) \]

Figure 9. 槳葉上的各種相關角度之分佈(J = 0.2)

Figure 10. 槳葉上的受力分佈(J = 0.2)

從上面的角度分佈圖(Figure 9)可以看出各種氣流角、誘導角、和最終合成的攻角等，在整片槳葉上分佈的比較平均而沒有像上一個案例那樣落差過大，又因為橢圓槳葉形狀的應用，在槳葉尖端也沒有出現前例那樣突然下跌的曲線；而另一張槳葉力分佈圖(Figure 10)也反應了同樣的結果，整隻槳葉的受力分佈更加均勻圓滑，而非像前例那樣趨向於集中在某個位置上。這樣的結果使得槳葉上比較不容易出現「這地方還沒達到最佳功效位置但那地方已經跌出最優範圍」的問題，當在最佳氣流狀態工作時，通常是整片槳葉的氣流狀況都處在高效區域內，使得槳葉在最佳狀態下的性能會比前例更加優秀；但是另一方面，當槳葉氣流處在不佳位置的時候，通常就是整片槳葉大多都在這樣的狀態下，所以這也會導致性能曲線比較陡峭，這將在下面的分析圖中可以看得出來。

Figure 11. 螺旋槳推力趨勢圖

Figure 12. 螺旋槳功耗趨勢圖

從推力變化圖(Figure 11)中能夠發現本例螺旋槳的推力隨 J 變化而升或跌的斜率比前例更大，並且更容易出現一個波峰狀的最佳表現區(如 K = 1.2、K = 1.4 這兩條線)，並在離開該位置的左右兩邊性能都立刻下跌，這也是前段所述的原因所造成。另外也注意到一個現象，雖然前面一直都說本例的改進比較優秀，但是在推力係數的最大值上面本例(最大推力係數約 0.1)卻沒有前例(最大推力係數約 0.175)來的好！這是因為橢圓槳的造型其實實質的減少了槳葉面積所致，因此也許它的效率可能比較好，但是當遇到寧可犧牲效率也要榨出最大動力的情境下，其表現卻可能不如前例的簡單平直造型！在功耗變化圖(Figure 12)上也能夠觀察出同樣的趨勢，改進後的本例螺旋槳在適合的工作範圍內所需要消耗的功率較低，然而在不適合的工作範圍時卻能夠比改進前的前例高出將近一倍！

Figure 13. 螺旋槳效率趨勢圖

最後來看效率圖(Figure 13)。基本上似乎沒有什麼意外，一切反應的狀況都如同在前段所分析的一樣。改進後的本例螺旋槳具有更加陡峭的效率曲線，最佳效率的作用區間明顯比改進前的竹蜻蜓更加狹窄，然而其在最佳工況之下的最佳效率(隨 K 值的不同，數值範圍約在 79% ~ 93%) 卻比前例(數值範圍約在 57% ~ 71%)表現明顯更加傑出許多。

此外還有一個現象也值得注意。比對效率圖(Figure 13)與推力圖(Figure 11)能發現，最大效率所在的 J 值與最大推力係數所在的 J 值並不在同一個位置上，其中最大推力係數對應的 J 值都小於最大效率對應的 J 值一段距離。並且不論是對於哪一個 K 值，或是在前面的竹蜻蜓案例上都能夠看到同樣的現象，甚至於在本篇實驗的許多 K 值之下，要得到最大的推力係數的話，幾乎總是 J 值愈小愈好！這現象在現實中的意義就是若我需要最佳的效率，用最省油的方式飛最遠的距離，那就要調整速度與轉速達到最佳比例；但是若我要的是寧犧牲效率多燒點油也要最大的推力輸出的話，那麼螺旋槳轉速就要愈高愈好，這點與前篇 ^[2] 所描述的規律相同；或者在轉速不變的情況下，航速愈低愈能得到更大的推力，這也與螺旋槳在地面測試時總能得出最大推力的實際經驗相符。

總結

在前篇介紹了經典螺旋槳分析算法後，本篇使用兩個具體的範例演示了螺旋槳性能的計算與結果比較。除了展示出螺旋槳上的氣流與性能分佈狀態之外，也展示了螺旋槳不同造形設計所產生的不同性能差異。其中扭轉槳葉的效果使氣流在整片槳葉上的分佈更加平均合理，但是也同樣造成當氣流狀況不佳的時候通常是整片槳葉都不佳的結果，從而使得扭轉式槳葉對氣流的反應更加敏感而非平滑變化；然而這點在擁有槳距調整機制乃至於恆速螺旋槳應用的情況下卻使這項問題並不那麼重要，反而其性能峰值更佳的這個表現結果更加受人所喜愛，這在當前眼界所及的所有螺旋槳幾乎全都採用這種設計構型的存在結果得到應證！然而幾乎在所有性能上都表現不佳的無扭轉的、平直矩型的槳葉造型，其實也是經常出現在我們生活中的視野範圍內。除了因其簡單廉價低成本特性而被大量應用在竹蜻蜓等玩具、廉價風扇等用途之外，還有一個可能一般人憶想不到的，並不廉價也不低成本卻也很愛使用這種造型的地方：直昇機！

並且本篇也透過更加貼近實際的空氣動力模擬計算印證了從前所整理的螺旋槳特性，即在需求最大推力的條件下螺旋槳轉速是愈高愈好(J 值小)，而在需求最佳效率的時候螺旋槳則要轉的愈慢愈好(J 值大)。且若再延伸思考又會發現另一條邏輯：螺旋槳的推力隨 J 值的增加而不斷下降，終將降至為零。這結論也遙遙預示了以螺旋槳作為動力裝置的飛行器，終究存在某種無法跨越的飛行速度上限！

最後，本篇所使用、及前篇所介紹的螺旋槳分析程式、以及本篇的分析案例結果資料，都在此提供下載 ^[3] 。

1. 螺旋槳 6：性能計算

2. 螺旋槳 2：變距螺旋槳

3. 本篇文章所使用的分析程式與分析結果

螺旋槳 6：性能計算

Mon, 06 Oct 2025 17:53:32 +0800

本篇我們要來做一件稍微硬核的事情，計算分析螺旋槳的性能！本篇使用的是 Blade Element Theory (BET)計算法，通常被使用來快速分析一個螺旋槳設計外型的粗略性能表現。除了產生的總推力和需要消耗的旋轉功率之外，也能透過分析讓我們一窺在槳葉上面的氣流分佈，了解螺旋槳的各種參數如轉速、槳距、和飛行航速之間的消長關係，以及誘導氣流在其中所佔據的影響力。

在往下分析計算螺旋槳的性能之前，讀者請記得先閱讀過關於機翼剖面型的升阻力計算內容 ^[1]，因為本篇的分析將以該篇之內容作為起點基礎。

螺旋槳的槳葉與飛機的機翼並沒有本質上的不同，都是翼片切割空氣產生相對氣流，然後氣流在翼片上產生作用力，只不過在一般機翼上的作用力被我們叫作升力與阻力，而在螺旋槳上面它們則是推力與轉矩。雖然螺旋槳看上去好像比常見的機翼更加複雜些，然而若再度請出祖傳的「用力分割法」將螺旋槳槳葉切割為許多的小塊 (如果是從我的航空系列文章一路讀下來的讀者應該已經很熟悉這種手法了)，則每一塊的情況都將變得相當單純了，能夠計算了。最後再把各小塊的計算結果加總起來，就得到了整體最後的結果。

Figure 1. 螺旋槳切塊與作用力示意 ^[2]

翼剖面型

在繼續更複雜的內容之前，首先要先來挑選將要使用在螺旋槳槳葉上的翼剖面形狀。一個實際螺旋槳上的翼剖面通常會有好多不同的形狀，從槳葉根部到尖端的每個位置都是不同的形狀，而在本篇的分析中為了簡單起見，整隻槳從頭到尾將只採用一個翼型。但是在本篇及下篇使用的分析程式中是有預留能夠在不同槳葉位置使用不同翼型參數的擴展空間的，讀者自己拿去使用的時候可以不用擔心受到本篇只使用單一翼型的限制。

雖然這裡說的是要決定翼型，但是在分析中其實我們並不關心翼型的實際長相，真正需要的只有該翼型的性能參數也就是升力係數($C_l$)與阻力係數($C_d$)而已。因此在本篇與下篇的分析程式中會發現沒有任何關於翼型的外型定義設定，只有翼型的升阻對應函式或表格而已。另外也是為了簡單起見，本篇並沒有使用實際的翼型參數表，而是使用簡單的數學式來模似翼型的性能表現。當然這點也並不影響程式的可用性，讀者自己拿去計算的時候同樣可以將其內容替換為實際使用的翼型參數資料。

本篇分析所使用的模擬翼型的升阻力係數之數學表達式如下：

\[ \alpha_0 = -2.1 \frac{\pi}{180} \]

\[ C_l = \begin{cases} 2 \pi ( \alpha - \alpha_0 ) & \quad \text{if } \alpha - \alpha_0 \leq 0.25 \\ \frac{1}{2} \pi \frac{\cos( \alpha - \alpha_0 )}{\cos(0.25)} & \quad \text{if } \alpha - \alpha_a0 > 0.25 \end{cases} \]

\[ C_d = \begin{cases} 0.224 ( \alpha - \alpha_0 )^2 + 0.006 & \quad \text{if } \alpha - \alpha_0 \leq 0.25 \\ 16.6944 ( \alpha - \alpha_0 )^2 - 1.0234 & \quad \text{if } \alpha - \alpha_0 > 0.25 \end{cases} \]

其中：
$\alpha$ 為攻角，也就是翼弦線與氣流的夾角；
$\alpha_0$ 為此翼型的零升力攻角。

將以上算式畫成圖表的話，那麼本篇所使用的翼剖面升阻參數就長成下圖(Figure 2 和 Figure 3)的樣子。可看出我們所使用的模擬翼型大約在攻角 12 度左右的位置會發生流場分離現象，大於那個角度之後的升力會開始下滑，並且阻力陡升。

Figure 2. 本篇模擬翼型之升力係數圖表

Figure 3. 本篇模擬翼型之阻力係數圖表

槳盤與槳葉(最簡單的分析)

Figure 4. 槳盤與槳葉的參數定義

上圖(Figure 4)是以槳盤為參考基礎下的一些幾何有關的各參數名稱定義。為了文章的單純化，避免過多雜亂的冗餘敘述，本篇全篇使用統一一致的名稱定義，因此許多在前面已經交代過的名稱意義，到了後面通常就不會再重複解釋交代了。

整隻螺旋槳的盤面直徑為 $D_p$，注意螺旋槳中央會有一部份的區域是會被排除在計算之外的，那部份通常就是螺旋槳中間的整流罩或是暴露的軸心結構區(槳轂區)，該區域的直徑為 $D_h$。

我們將一片槳葉以螺旋槳軸為中心，依據不同的半徑距離將槳葉切割為許多小塊 (切的愈多計算就愈準，至於上圖只是示意就無需較真切塊的數量)。我們抓取其中被青色斜線標記的那一塊來看，可知這一個小塊方形區域的長寬分別為 $dr$ 和 $c$，面積就是 $ dr \cdot c $。其中 $dr$ 的大小和小區塊分割的數量有關，區塊數量分個的愈多則 $dr$ 愈小。好的，這裡我大概知道你想要問什麼問題。沒錯，這其實實際上並不會是一個真正的長方形，因為槳葉的寬度可能是漸變的；但是這種分別切割計算的方式之所以能有效降低問題的複雜度，就在於無視單一格子內的數字差異變化而統一視之。因此在上面的切割圖之下，每一個小區塊內就不存在外型增寬或縮窄的問題，因此它就是個長方形。 (也因此，這就是為什麼區塊切的愈多就算的愈準，而切的愈少則誤差愈大！)

這一個槳葉小塊距離轉軸中心的距離為 $r$。那麼假設螺旋槳的轉速為 $\omega$ (注意這裡的轉速單位不是一般市井通用的 RPM， 而是在數學計算領域中更加通用的轉速單位：每秒徑度，也就是 rad/s)，那麼這個槳葉小塊因為旋轉而產生的前進速度就是 $ r \cdot \omega $。如果暫時先不考慮一些其它細節的話，那麼到這裡我們就什麼都有了！這個槳葉小區塊在旋轉的迎風氣流下會產生的升力與阻力，都能夠使用在前篇 ^[1] 已經介紹過的內容來做計算：

\[ V_b = r \cdot \omega \] \[ dLift = \frac{1}{2} \rho {V_b}^2 ( c \cdot dr ) \cdot \mathit{C_l}(\alpha) \] \[ dDrag = \frac{1}{2} \rho {V_b}^2 ( c \cdot dr ) \cdot \mathit{C_d}(\alpha) \]

其中：
$V_b$ 為槳葉小塊所受到的相對氣流；
$dLift$ 為槳葉小塊產生的升力；
$dDrag$ 為槳葉小塊產生的阻力；
$\rho$ 為空氣密度；
$\alpha$ 為攻角，即槳葉小塊弦線與氣流之間的夾角，目前為止這個攻角就等於槳葉在該位置所造出的扭轉角度，也就是在後面會出現的 $\beta$ 角；
$\mathit{C_l}()$ 為槳葉翼型的升力係數函式，代入攻角 $\alpha$ 後得到升力係數；
$\mathit{C_d}()$ 為槳葉翼型的阻力係數函式，代入攻角 $\alpha$ 後得到阻力係數。

這樣我們就計算出了一個小區塊所產生的力，其中的升力就是槳葉推力，阻力就是槳葉阻力，而對螺旋槳軸產生的轉動力矩則就是槳葉阻力乘上力臂長度(也就是槳葉小塊所在的槳葉半徑位置 r)就是了。那麼這單一一個小塊所產生的推力(Thrust)、轉軸扭矩(Torque)、和需要消耗的轉動功率(Power)也就是需要發動機提供動力來對抗的功率，以上三個數值分別就是：

\[ dThrust = dLift \] \[ dTorque = dDrag \cdot r \] \[ dPower = dTorque \cdot \omega \]

其中為了區別單一小塊和整副螺旋槳所產生的作用力，這裡給單一小塊的作用力都加上一個前綴 d。

最後再把所有的小區塊結果通通計算出來，然後全部加一起，就是整隻槳葉的結果了。最後的最後看這螺旋槳有幾隻槳葉，再將結果乘上槳葉數量 N，就能得到整副螺旋槳的最終結果：

\[ Thrust = N \sum dThrust \] \[ Torque = N \sum dTorque \] \[ Power = Torque \cdot \omega \]

這樣有沒有覺得很簡單啊？就這麼簡單就把螺旋槳的性能給計算出來了！原理就是這樣沒錯，不過在上面的計算中其實忽略了相當多的其它條件，所以計算的結果會和實際上相當有落差。不過以循序漸進的角度來看，目前這樣的程度算是夠用了，已經足夠建立起後面要逐漸深入的前導知識概念。那麼接著繼續往下，我們就要繼續把更多的影響因素給加進來，複雜度會逐漸升高，但也能讓我們得到更加接近真實的東西。那就準備好繼續往下閱讀吧！

考慮飛行速度

Figure 5. 槳葉切片小塊的剖面幾何與相關氣流參數定義

前面的螺旋槳分析算法過於簡單，沒有考慮到飛機本身正在以某個速度飛行所帶來的相對氣流對螺旋槳產生的影響。因此接下來我們就把飛機飛行的速度加入我們的計算模型內，也就是為我們的螺旋槳加入一個垂直於盤面的氣流速度 ($V_\infty$)，其即為前述之飛機飛行速度所帶來的相對氣流。

在考量 $V_\infty$ 存在的情況下，仍然能夠沿用前面介紹過的算法概念，只需要修改調整其中的部份算式內容。那麼這次就讓我們繼續將焦點放在其中一塊槳葉小塊，只不過從俯視的角度轉向側視，從側面的角度觀看分析槳葉小塊的剖面、以及其上的氣流與受力，如圖(Figure 5)所示。其中槳葉的受到的相對氣流 $V_b$ 不再完全等同於 $ r \cdot \omega $，而是由 $ r \cdot \omega $ 和 $V_\infty$ 這兩個互相垂直的氣流所合成的氣流。那麼 $V_b$ 的大小就能夠使用直角三角形邊長的計算法，或由三角函數算法來求得 (很明顯本篇選擇使用三角函數算法，但讀者想要自己計算驗證的話也可以嘗試使用直角三角形算法)，而 $V_b$ 與槳葉旋轉運動方向之間就會產生一個 $\varepsilon_b$ 的夾角。這時槳葉的氣流攻角就不再等同於槳葉安裝角(Pitch Angle ($\beta$))，而是 $\beta$ 減去 $\varepsilon_b$ 後的夾角。最後還要注意翼片的升阻力定義是垂直與平行氣流的力，那麼在當前的情況下這兩個力(也就是示意圖中的 L 和 D 兩力)就和螺旋槳推力方向與轉矩方向產生了一個夾角，在計算的時候也需要考量到這一點。

那麼在大部份沿用前面描述的算法之下，需要調整變更的算式如下：

\[ \varepsilon_b = \tan^{-1}( \frac{V_\infty}{ r \cdot \omega } ) \] \[ \alpha = \beta - \varepsilon_b \] \[ V_b = \frac{ r \cdot \omega }{ \cos(\varepsilon_b) } \]

\[ dThrust = dLift \cdot \cos(\varepsilon_b) - dDrag \cdot \sin(\varepsilon_b) \] \[ dTorque = r ( dDrag \cdot \cos(\varepsilon_b) + dLift \cdot \sin(\varepsilon_b) ) \]

就這樣經過簡單的計算式調整，至於其它沒調整的部份則全部繼續沿用原有的內容，然後我們就能夠處理具有飛行前進速度下的螺旋槳性能分析計算了！有沒有很簡單啊？

考慮誘導氣流

Figure 6. 螺旋槳誘導渦流示意圖 ^[3]

我們知道在運轉中的螺旋槳上面是存在誘導渦旋氣流的 ^[4] 。如果說這個誘導氣流對螺旋槳造成的影響夠小的話，那麼倒是可以無視它的存在；問題是在實際的情況中這個誘導渦旋不只存在，影響還佔相當大的比例，如果忽略的話那結果的誤差還挺大的！所以接下來我們就要加入考量誘導渦旋存在的情況。這會讓整個情況變得更加複雜，且讓我們繼續研究下去……

Figure 7. 加入誘導氣流後的槳葉切片剖面幾何與相關氣流參數定義

如同上圖(Figure 6)所表示的那樣，當螺旋槳葉片在旋轉攪動空氣的時候，槳葉產生高氣壓的一側空氣會從葉片尖端翻越過去，形成一股從葉尖引發的渦旋，吹襲整片槳葉、以及也會同樣影響其它槳葉。所有的一切分析概念和計算方法仍舊繼續延續前面已經得到的結果，只不過同樣需要修改當中的一些東西，加入考量誘導氣流存在的狀況。讓我們繼續專注於槳葉小塊的剖面視圖(Figure 7)。

在這張圖片(Figure 7)中，雖然看上去好似有些複雜，但其實基本都和前一張圖是一模一樣的，只不過多了一個由誘導流所產生的氣流($V_i$)，至於 $V_{i\infty}$ 和 $V_{i\theta}$ 則是 $V_i$ 在推力軸上和葉片旋轉方向上的分量。另外要注意到 $V_i$ 是垂直於最終氣流 $V_b$ 的，而不是平行於自由氣流 $V_\infty$，原因與升力阻力的方向定義建基自由流相同。另外還有一個神奇的問題，這個誘導流 $V_i$ 到底多大呢？剩下的兩個氣流都很容易取得，一個就是飛機行進的速度而另一個就是螺旋槳旋轉的速度乘上半徑，但就惟獨不知道這個誘導流的大小到底是何？關於這部份是有些困擾但不大，我們先暫時放下誘導流的大小到底多大的這個問題，待到後面再回來想辦法解決。因此接下來我們就先暫時忽略 $V_i$ 到底怎麼算的部份，就先假定我們已經使用魔法知道它多大了！

那麼在解決了 $V_i$ 怎麼得來的問題後， $V_i$ 就成了個已知數，同樣的誘導角 $\varepsilon_i$ 也就連帶為已知，那麼剩下的事情就好辦了！在延續前面考慮了飛行速度所得出的計算概念和算法之下，進一步我們需要修正下面這幾條計算：

\[ \varepsilon_\infty = \tan^{-1}( \frac{V_\infty}{ r \cdot \omega } ) \] \[ \varepsilon_b = \varepsilon_\infty + \varepsilon_i \] \[ V_i = r \cdot \omega \frac{\sin(\varepsilon_i)}{\cos(\varepsilon_\infty)} \] \[ V_{i\theta} = V_i \sin(\varepsilon_b) \] \[ V_{i\infty} = V_i \cos(\varepsilon_b) \] \[ V_b = r \cdot \omega \frac{\cos(\varepsilon_i)}{\cos(\varepsilon_\infty)} \]

你看，很簡單吧！建立在前面的基礎之下，僅僅修改這麼一點點東西就能夠套用了！ (當然這時候少不了一點點苦笑)

求解誘導流

前面我們蒙著眼睛假裝已經知道誘導流的大小，並且整理完了剩下的所有計算。然而這個誘導流不能夠一直懸而未解啊！如果要真實的完成所有的計算去分析一個螺旋槳，總歸還是得面對這個問題。那麼本節就來繼續解決關於求解誘導流的這個問題，補上最後這一塊拼圖。

關於這個問題我們使用基於環流理論的研究成果來解算 (就是好久以前我曾簡單介紹過的那個環流理論 ^[5] ，這次終於給大家演示一遍實際應用了)。根據 Goldstein’s Vortex Theory ^[6] ：

\[ N \Gamma \cong 4 \pi r f V_{i\theta} \] \[ \Gamma = \frac{1}{2} V_b \cdot c \cdot \mathit{C_l}(\alpha) \] \[ f = \frac{2}{\pi} \cos^{-1} \left\{ \exp\left( \frac{ -N \left( 1 - \frac{ 2 r }{D_p} \right) }{ 2 \sin(\beta_t) } \right) \right\} \]

其中：
$\Gamma$ 就是當下這個槳葉小塊所產生的環流強度；
$f$ 為 Prandtl’s tip loss factor；
$\beta_t$ 則為槳葉尖端翼型的扭轉角 $\beta$。

稍微整理調整一下上面的計算式可得：

\[ N \Gamma - 4 \pi r f V_{i_\theta} = 0 \]

仔細左看右看思考一下就會發現上面這條式子裡面所有的數都是已知的，除了 $\varepsilon_i$ 之外。那麼一個方程式只有一個未知數，肯定能夠求解了！基本上個人覺得上面的方程式對於程式寫作來說算是比較友好的，但如果讀者不把它展開會犯強迫症，或者不習慣到處來回參閱相關的其它計算式的話，那麼也是可以將這個方程式所需要用到的前面那些計算式全部代入進來並展開，那麼就會得到下面這條式：

\[ \frac{N c}{16 r} \mathit{C_l}( \beta - \varepsilon_\infty - \varepsilon_i ) - \cos^{-1} \left\{ \exp \left( \frac{-N \left( 1 - \frac{2 r}{D_p} \right)}{2 \sin(\beta_t)} \right) \right\} \tan(\varepsilon_i) \sin( \varepsilon_\infty + \varepsilon_i ) = 0 \]

把算式展開以後，應能更加看得清楚整條式裡面真的就只有 $\varepsilon_i$ 這麼一個數是未知的，肯定可以求解了！只不過請先別緊張，雖然理論上這條式子能夠求解，但是這看上去這麼複雜的方程式，真的要分析解的話應該會先去掉半條命吧！於是面對這種方程式，我們通常會請出真正的魔法工具出來解算。那麼這種聽起來好像很厲害的解法到底是怎麼解算呢？說出來可能能讓你正在喝的水噴出來，核心秘訣就一個字：猜！是的，就是這麼樸實無華。那個方程式右邊不是零嗎？那我們就給 $\varepsilon_i$ 隨便猜一個數字代入方程式左邊算一算，最後算出來的結果肯定不是零；但是我們一直繼續猜，不斷的猜，最後總會找到一個數字能讓計算的結果等於零或者相當接近於零，那麼我們就當作最後這個能讓計算結果接近於零的 $\varepsilon_i$ 就是方程式解了！

Tip	上面的解算方法看著描述好像有點無厘頭，然而這其實就是所謂的數值計算方法(Numerical Methods)。那些使用電腦的計算力來求解複雜函式的方法核心其實也就是猜，只不過使用了可能更有效率，猜的更快的猜法策略而已。

搞定了 $\varepsilon_i$ 解算的問題之後，剩下來的事情我們都已經知道該如何做了。把 $\varepsilon_i$ 數值代入進去，槳葉小塊的各力就能計算出來，再匡匡一頓操作，整副螺旋槳的性能數據也就順手做出來了！當然相關的計算量會相當龐大，除了因為把槳葉大量切成一塊一塊本身就是相當的計算量之外，每一個小塊為了求解誘導角還得反覆橫猜。不過這時候請千萬不要說什麼用手算要算到天荒地老之類的話，因為作為我們現代人，這種苦工沒有人在自己用手算的，請妥善利用電腦來做這種苦差事！

效率

至此我們已經有能力把一副螺旋槳的推力、扭力等性能給計算出來，接下來介紹如何計算螺旋槳的效率。

螺旋槳的效率是什麼意思呢？就和齒輪傳動的效率是一樣的！如果類比套用我從前介紹過發動機效率的原理 ^[7] ，那麼螺旋槳其實也能是一個黑盒子機器，它的作用就在於將旋轉形式的機械能量，轉換為向後加速空氣並推動飛機前進的能量。那麼在這樣的能量轉換過程裡面可能就會產生一些損失，而存在損失的話，自然就會有損失多還少的問題，也就是轉換效率多少的問題。

Figure 8. 管道中的螺旋槳推動氣體向後移動

要計算螺旋槳效率，首先要計算的就是轉換前、後的能量是多少，也就是輸入與輸出的能量是多少？輸入螺旋槳的功率其實我們已經知道了，就是前面計算式裡面的 Power，也就是螺旋槳的扭力乘上轉速；那麼輸出呢？螺旋槳的最終作用就是推動氣體向後移動，如同上圖(Figure 8)所示，因此螺旋槳的推力乘上氣體移動的速度就是螺旋槳的輸出功率了。推力多少我們已經知道了，那麼氣體移動速度是多少呢？欸～這可不就是前面已經設定好的自由氣流的速度了嗎(其實也可以理解為就是飛機前進的速度)？於是螺旋槳的推進效率($\eta$)就是：

\[ \eta = \frac{ Thrust \cdot V_\infty }{ Torque \cdot \omega } \]

係數化

現在我們終於把一副螺旋槳的性能數據都能計算出來了，包含推力、扭矩、功率和效率等，但是還尚缺少最後的一步，那就是將這些數據給係數化；至於係數化的意義如同前篇的介紹 ^[1] 一樣，是為了儘量降低螺旋槳性能數據與其它變量的牽扯關係，儘量讓數據只和螺旋槳的設計本身有關係。

首先來對尺寸的部份進行無因次化。為了讓螺旋槳的尺寸相關數字與具體的尺寸單位、乃至於與具體的螺旋槳大小無關，我們將所有的尺寸相關數字都轉化為某個螺旋槳最具代表性尺寸的比例關係，而這個最具代表性的尺寸就是槳盤直徑 $D_p$。因此我們用數值範圍在 0 ~ 1 的比例 R 來取代具體的半徑 r：

\[ R = \frac{ 2 r }{D_p} \]

螺旋槳的螺距或槳距($\lambda$)就是把螺旋槳當螺絲來看的話，旋轉一圈所推進的距離，而這個距離我們也改用與槳盤直徑的比例關係 K 來替代：

\[ K = \frac{\lambda}{D_p} \] \[ \lambda = 2 \pi r \tan(\beta) \]

然後是關於槳葉的旋轉速度與自由氣流速度，從前介紹過槳距以及槳距調整的相關內容 ^[8] ，我們知道這兩者之間的消長關係與螺旋槳的性能表現可影響太大了。但是再仔細分析又發現，該二者的具體數值真正是多是少其實影響不大，真正重要的其實是兩者的比例關係(也就是反應在前面所有算式裡面的 $\varepsilon_\infty$)。於是我們用一個兩者速度的比例關係值 J 來取代對於前述兩個速度的表達：

\[ J = \frac{ 2 \pi }{\omega} \frac{V_\infty}{D_p} \]

再來就是整副螺旋槳的推力係數($C_{Thrust}$)、扭矩係數($C_{Torque}$)、和功耗係數($C_{Power}$)了：

\[ C_{Thrust} = \frac{Thrust}{ \rho \left( \frac{w}{ 2 \pi } \right)^2 D_p^4 } \] \[ C_{Torque} = \frac{Torque}{ \rho \left( \frac{w}{ 2 \pi } \right)^2 D_p^5 } \] \[ C_{Power} = \frac{ Torque \cdot \omega }{ \rho \left( \frac{w}{ 2 \pi } \right)^3 D_p^5 } = 2 \pi \cdot C_{Torque} \]

最後的效率($\eta$)其實本身已經就是無因次量了，無需多做轉換。但是除了使用原始的推力功耗等數據來計算之外，在已經擁有上述各項係數值的前提下，也可以從這些係數簡單計算出來：

\[ \eta = \frac{ Thrust \cdot V_\infty }{ Torque \cdot \omega } = \frac{C_{Thrust}}{C_{Power}} J \]

結語

本篇介紹了在螺旋槳分析用途上相當經典的 Blade Element Theory 演算法，是學術分析以及早年的設計分析上相當重要的設計分析方法，可以在直接上材料做風洞實驗之前就能夠先算出來相當具有指標性的大致結果。當然在現代計算流體力學(CFD)的大量應用之下，可以更細緻且準確的模擬出實際流場會發生的實際現象，也能讓設計人員更加直觀的看出一些流場細節，因此讓這個經典分析算法的重要性下降了(從那些參考文獻的時間都在二次大戰之前大概就能夠看出來)。然而這個經典算法雖然重要性下降但還是相當有用的，它在現代可能更大的價值在於快速分析一個陌生螺旋槳外型的性能參數估算，或者在螺旋槳設計的前期可以非常快速的得出幾個不同方案之間的性能估計。畢竟相比於建模、建網格、輸入條件參數然後正兒八經的跑 CFD，本篇介紹的這個經典的算法可太簡單快速方便彈性了！在下一篇將要進行的實際按例分析就可以看出來，若將那些分析全都使用 CFD 去跑，那可真是耗時耗力的啊！

最後再來談談屬於我的心路歷程。其實本篇所介紹的演算法，就是我在大學時期某一堂課的學期作業。記得在學期結束的時候，整個年級就兩個人交出了這份作業，在那個時候可讓我相當得意的呢！時隔多年，為了製做本篇內容，我又將埋藏多年的程式碼給挖了出來。當時那份程式碼是用 Fortran 寫的，我就以 Python 重寫了一遍，還順手發現了舊程式碼裡面其實存在有一些小錯誤！時隔多年重新進行同樣的工作，心中頗有感觸。想當年在學校偶然聽聞在低年級的同學老師間流傳說我是「Fortran 大神」，但其實在畢業之後真正做上第一份工作就知道只是個菜鳥中的菜鳥。多年之後雖然也稱不上什麼真正的大神，倒是肯定自信是個具有相當經驗的老鳥。再回過頭來寫程式碼，發覺許多心態都變了，對於設計的思想哲學和各種矛盾取捨之間的調和甚至與以往能是完全相反的！

對於本篇多次提到的這個計算程式，由於篇幅的關係，本篇就只介紹演算法，待到下一篇再進行一些實際的分析展示。因此相關的計算程式和結果資料也同樣就放到下一篇再開放下載了。

5. 翼型系列 3：那些升力原理哪裡錯了？

6. The Application of Goldstein’s Theory to the Practical Design of Airscrews

7. 活塞引擎 7：功率與效率

8. 螺旋槳 2：變距螺旋槳

翼型系列 6：升阻係數

Sun, 31 Aug 2025 01:09:28 +0800

本篇要來說明如何從機翼剖面的幾個係數去計算升力阻力等作用力。

為什麼會隔了這麼多時間後突然更新翼型系列的文章呢？原來我是沒有計劃寫這篇，本來的翼型系列在寫完第五篇就算完結了。機翼的各種係數和升阻力等的內容已經偏向計算細節，對於科普介紹理解的目的來說已經遠超出所需要的知識範圍。但是最近正在進行螺旋槳系列的寫作，即將要進行一些性能計算分析，正好就會需要計算葉面的升阻力，就發現還是得先交代一下翼剖面升阻力的計算相關議題。當然也可以忽略這些不去解釋而直接套用結果計算式，但是這麼做的話很可能會讓那些除了曾經學習過相關知識的人之外的其他人感到困惑不解，而如果在螺旋槳篇章裡面去交代這些東西的話又會讓文章過度龐雜，因此判斷有必要以獨立的主題去交代這些有關的事情。於是就這麼誕生了翼型系列經過多時之後的新篇主題。

作用力之計算與相關定義

Figure 1. 機翼剖面、氣流與作用力定義

如上圖(Figure 1)所示為一個機翼剖面形狀在氣流中與其所產生作用力之關係圖。其中剖面形的前緣端點到後緣端點之間的連線叫作「翼弦」(Chord)，其長度也就是弦長。翼弦就是翼剖面形的基線，凡與機翼的尺寸、或與氣流之關係等之描述，皆是以其作為基準。前方吹來的氣流我們有時候稱為「自由流」(Free Stream)，其速度通常即為飛機前進的速度；而其與翼弦之間的夾角則為「攻角」(Angle of Attack (AOA))，仰頭向上為正，低頭向下為負。氣流吹過機翼會產生作用力，其垂直於自由流的分量即稱為「升力」(Lift Force)，升力可能為正可能為負，比方機翼負攻角低頭達某個程度的時候，產生的升力就是向下的負升力；而作用力平行於自由流的分量稱為「阻力」(Drag Force)，阻力只能是正的，至少在目前人類能造出來的實物裡面不可能產生負阻力的狀況。

最後就是力矩的部份，氣流吹過機翼時不只產生作用力，還產生了作用力矩(Moment)，在一般通常的常見情況下產生的是使機翼低頭扭轉的力矩；但是上圖力矩的方向怎麼畫反了呢？！那不是畫反了，而是因為定義的關係！因為攻角定義仰首方向為正，因此力矩的方向也就同樣定義以仰首為正了，否則力矩和攻角的定義會互相衝突。這就是為什麼下面我們將要看到的一堆力矩係數基本全都是負值的原因了！另外，既然提到力矩那就不能不交代其之基準中心點。一般情況下我們定義機翼上各種力與力矩作用的中心點，是在翼弦上的前方四分之一位置處，這個地方稱為「氣動中心」(Aerodynamic Centre (AC))；至於為什麼氣動中心定義在這裡，而不是定義在力矩為零的整體作用力中心上？這個後面再談。

知道了翼型剖面相關的定義之後，我們要如何計算各種作用力的大小呢？這時候我們還需要知道幾個係數，也就是「升力係數」(Lift Coefficient ($C_l$))、「阻力係數」(Drag Coefficient ($C_d$))、和「力矩係數」(Mement Coefficient ($C_m$))。其實詳細來說這不是三「個」係數，而是三張圖表，你從哪裡取得的翼型資料通常會有這些數據；而如果沒有的話，恐怕就得自己做實驗來得到了！有了係數之後，其對應的力和力矩就能通過下列的計算式算得：

\[ L = \frac{1}{2} \rho V^2 S C_l \] \[ D = \frac{1}{2} \rho V^2 S C_d \] \[ M = \frac{1}{2} \rho V^2 S c C_m \]

其中：
$L$ 為總升力；
$D$ 為總阻力；
$M$ 為總力矩；
$\rho$ 為空氣密度；
$V$ 為自由流速度；
$S$ 為機翼投影面積；
$c$ 為翼弦長。

其實其中的那個 $ \frac{1}{2} \rho V^2 $ 在空氣動力學上面就是動壓，若以 Q 表示動壓的話，那麼上面的計算式還能寫的更為簡潔：

\[ L = Q S C_l \] \[ D = Q S C_d \] \[ M = Q S c C_m \]

不過實際上其實並沒有看上去那麼簡單單純。前面有說到，這其實不是三個係數而是三個係數表，這些係數實際上會隨著攻角(AOA)的變化而不同。此外機翼在不同的雷諾數 (Reynolds Number ^[1]) 下的係數表也有所不同，不過本篇我並不想展開解釋關於雷諾數的部份，那也不是三言兩語能說得清的，如果讀者不知道什麼是雷諾數的話，可以姑且理解為就是自由氣流的速度 (至少在我們所專注的應用裡，雷諾數與其它參數的影響關聯較小些)。所以粗淺來說，我們可以簡化理解為某個機翼剖面形的這些係數只會與攻角產生對應關係！

Figure 2. 矩型機翼的尺寸與面積 ^[2]

上圖(Figure 2)就是一架採用矩形翼的小飛機，我們可以清楚的看到它的剖面形狀。我們所說的機翼面積一般就是指機翼的平面投影形狀的面積，以上圖的矩形翼來說那就是翼剖面弦長(Chord)乘上翼展寬度(Span)的結果，計算出來的這個面積就是在前面算式中需要代入的機翼投影面積，簡稱機翼面積。

當然對矩形翼來說是如此簡單，但如果其它要計算的飛機它的機翼沒有這麼中規中矩呢？比方說梯形翼、三角翼、橢圓翼，還有現代很多難以描述的融合形狀？對於這些機翼形狀比較奔放的飛機來說，我們就需要找到一個可以代表整片機翼綜和結果的「平均翼弦」；至於這個平均翼弦該如何計算如何找？甚至於如果機翼端部是一個剖面形，根部又是另一個剖面形，從頭到尾用的不是同一個翼剖面又該怎麼計算？這就已經超出本篇專注的範圍之外了，就不深入探討細節。況且實際上的三維機翼計算還不是這麼簡單乘上面積就完事了，因為你還得考慮翼尖誘導渦旋氣流 ^[3] 所造成的升阻力消長。因此本篇的重點還是放在二維空間上專注對於翼剖面形的計算。

實際案例與分析

前面已經交代了翼剖面三係數與作用力的計算，但是這三係數怎麼來的呢？正常來說對於任何一個翼剖面形丟給你，你得去做實驗才能得到這些係數的圖表，好在有些機構有公開發佈一些翼型的實驗結果，使我們可以不用真的造模型出來去吹風洞就能直接取用現成的資料。其中最為著名的大概就是美國 NACA (也就是家喻戶曉的 NASA 機構的前身) 公佈了許多該機構研究的翼型的資料，包括翼型幾何形狀以及實驗結果等。這大概就是為什麼許多自製飛機等用途大多愛用 NACA 幾號幾號翼型的原因吧！同樣基於不想自己動手做實驗的原因，本篇也就直接挑選了 NACA 系列翼型來作為分析按例。本篇所使用的翼型資料以及實驗圖表等都擷取自 1945 年出版的「Summary of Airfoil Data」 ^[4] 這份報告，有需要深入研究的讀者可以自行前往下載。

本篇所挑選的主要翼型型號是 NACA 2412，一款中規中矩的翼型，它的長相就像下圖(Figure 3)那樣，此外還有一些其它作為對比的翼型長相如另一張圖(Figure 4)所示。

Figure 3. NACA 2412 翼剖面型

Figure 4. 作為對比的數款 NACA 翼剖面型

升力係數

Figure 5. NACA 2412 升力係數圖表

Figure 6. 其它幾款翼型升力係數圖表

上圖(Figure 5)就是 NACA 2412 的升力係數圖表，另外一張(Figure 6)則是可作為比較對比的，其它幾種翼型的升力係數圖表。 (參考文件裡面收錄了大量翼型的實驗資料， 所以可能是由於節省版面的原因，原圖將升力係數與力矩係數畫在同一張圖表裡。 為了讓沒有接觸過相關領域的人不會被它混亂的內容所迷惑， 我做了一些淡出處理，使讀者可以一眼看出應該要聚焦或可以忽略的部份。)

可以看到升力係數與攻角之間基本就是呈線性關係，在攻角高到一定程度的地方升力係數會掉下來，那是因為氣流已經分離(失速)了，這點以前有解釋過 ^[5] 。同樣的，低頭(負攻角)到一定程度也會發生失速，於是在那裡也同樣產生了一個升力係數線圖的回凹現象 (對比的那張圖則沒有將實驗數據覆蓋到負攻角失速的區間)。

長相不同的翼型們升力係數的表現似乎都是驅同的，較大的差別只在失速攻角的不同，以及升力線彼此之間有一段距離的平移關係。這是因為機翼主要就是通過折轉自由氣流來產生升力的原理 ^[6] ，這就是為什麼升力與攻角呈線性關係(在氣流不分離的相對小範圍內)的主要原因，也因此不同形狀的翼型之間在此作用上沒有太多根本性的差別。不同翼型之間的差異主要體現在氣流的流暢性上面，也就是在阻力的表現上，以及所導致的失速攻角不同，失速緩和程度不同的表現上；至於在正常攻角範圍內的升力表現則不會有太大的差別。

因此當我們說「某些翼型適合低速使用，在低速下能產生更多升力」時，這個描述其實並不是嚴格正確，因為各種翼型的升力係數趨勢基本是一樣的！嚴格正確的解釋應該是說某些翼型可以容許更高的攻角(當然這時得從理論的零升力基準開始算)使用而不失速，所以所謂能產生更大升力的本質其實來自於更大的邏輯攻角。

Figure 7. 帶弧翼型在某個負攻角時產生零升力，該攻角即為「零升力攻角」

不同翼型之間的升力線段還呈現出平移的差異，這主要是因為翼型的彎曲度所造成的。機翼產生升力的根本原理是由於折轉了自由流所產生的反力，這個反力與偏折氣流的角度成正比。而翼型的彎曲度就相當於給氣流偏折的效果，雖然零攻角的時候翼型看上去是平擺著的，然而因為彎曲弧的存在，氣流吹過之後就會因此產生偏折 ^[6]。也就是說這個彎曲弧相當於已經給了一個基準的氣流偏角，要使機翼不產生側向力(升力)，也就是整體不偏折自由流，則機翼應當低頭到某一個角度才會產生這樣的結果(如上圖 Figure 7 所示意)。也就是說，其實那個不產生升力的角度才是理論上的基準狀態，也就是純理想的零攻角理論上應該是這種狀態；但是現實上因為我們定義的攻角是翼弦與自由流的夾角，而非零升力基準線與自由流夾角，因此這兩者之間就自然存在一個偏移量。這就是導致不同翼型之間升力線段彼此可能存在一個攻角偏移量的原因。

既然從實驗數據中知道升力與攻角呈線性關係，至少在未達或甚至未接近失速時的「正常工作攻角區間」內是如此，那麼在許多的計算用途中，我們就可以將升力係數簡化為下列關係式：

\[ C_l = {C_l}_\alpha ( \alpha - {{\alpha_C}_l}_0 ) \]

其中(前面已經解試過的相同符號就不再重複解釋)：
$\alpha$ 為攻角；
${{\alpha_C}_l}_0$ 即是「零升力攻角」(Zero Lift AOA)，就是在此攻角下產生之升力為零；
${C_l}_α$ 為一個比例常數。

既然都已經有了確實的實驗數據了，為什麼我們還要弄出一個既不完全準確，還只能在有限的操作攻角內有效的關係式出來呢？這有兩個好處，首先是整理歸納出來的關係式可以讓我們從更加直觀的角度閱讀數值之間的關係；再來則是在許多數學方程的解算中，一條關係算式肯定是比一個查表表格更加好用的多！

阻力係數

Figure 8. NACA 2412 阻力係數圖表

Figure 9. 其它幾款翼型阻力係數圖表

上圖(Figure 8)是 NACA 2412 的阻力係數圖表，以及另外一張圖(Figure 9)是數種翼型的阻力係數圖表作為比較使用。相較於不同翼型在升力表現上驅同，在阻力的表現則有些百花齊放了。原因就如同前面在升力係數部份所解釋的內容，不同形狀的翼型主要差異在於氣流的流暢度不同，因此就全體現在阻力上了！並且不只是形狀的不同能導致阻力表現上的差異，連不同的雷諾數都能導致阻力的表現產生出相當大的差異。

其實在人類向天空探索的早期，對於飛行器的設計是大量借鑑(抄襲)了已經飛的很好的資優同學：鳥類，其中就包括了機翼剖面的形狀基本也是從抄襲模仿開始。這個現象一直延續到大約萊特兄弟的時代，才漸漸被更加科學的研究成果所更新。當時的人們在試驗中發現這個機翼的效果怎麼並不怎麼好啊？！明明鳥類經過億萬年的演化，這個形狀應該是就最高效最優秀的(事實上也真的是)，可怎麼放到飛機上卻完全不是這麼回事？喔，原來是因為雷諾數差距太大了啊！人類自己建造的飛機，無論在體型大小上或是在飛行速度上，都和常見的鳥類差距頗大，也因此導致原本經過億萬年千錘百鍊的最佳造型突然換個地方就效果差強人意的結果。這就是為什麼現代飛機機翼的剖面形狀和鳥類的翼剖面形狀差別相當大的主要原因了！

回到圖表來，注意上面的圖表是呈現升力係數對應阻力係數的關係，而非攻角對應阻力係數的關係，主要因素應該也是因為那份報告因為版面的因素而將圖表給合併了，而我也沒有大費周章去修改這份圖表。不過也正好因為這樣的圖表佈局，可以讓我們清楚的觀察到翼型的阻力與升力成高度關聯性。與升力係數關係式類同，人們也歸整出了阻力係數的關係式：

\[ C_d = {C_d}_0 + k C_l^2 \]

其中：
${C_d}_0$ 就是在零升力狀態下的阻力，也就是該翼型的最小基礎阻力；而
$k$ 為一個比例常數。

力矩係數

Figure 10. NACA 2412 力矩係數圖表

Figure 11. 其它幾款翼型力矩係數圖表

上面同樣也是 NACA 2412 的力矩係數圖表(Figure 10)，和其它數種翼型的力矩係數圖表(Figure 11)。翼剖面上的力矩主要是因為翼型的彎曲弧度所造成的。氣流因為翼弧的緣故被機翼給繞著甩了一下畫了個弧，因此反作用力就形成了在機翼上的這個力矩。如果機翼的上下表面是對稱的，那兩邊畫的這個弧造成的力矩就可以彼此對削掉，所以對稱翼的力矩係數通常就在零左右。

另外一種說法是說，在機翼上的綜和合力施力中心其實一般不在我們所定義的支點中心(也就是翼弦的前方 25% 位置處)上，因此在存在力臂的情況下自然導致產生一個轉動力矩。這個說法也不能說不對，如果這樣能比較容易想像的話倒也是可以這麼理解 (；只不過實際照這想法分析計算的話，會在帶弧機翼的負升力情況下得到令人匪夷所思的現象， 有興趣的讀者可以自己嘗試看看，很好玩的！) 但是借用這個思路，也能夠解釋為什麼一般都將升力中心設定在翼弦前段四分之一的位置上。因為將參考支點放在這個位置的話，會發現無論攻角怎麼變化(當然還是得在「正常操作區間範圍」內)，那麼這個力矩就幾乎是無變化的，也就是力矩與攻角無關，力矩係數基本會是個常數。這個現象可太重要了，否則若我們將支點中心定義在其它位置上的話，那麼在後續各種計算上需要參考計算的項目就會更多，會讓計算分析更加複雜！而將支點定義在這個巧妙的位置上，在許多計算分析上就可以將力矩假設為常數，或甚至在有些情況下可以不用考慮它的存在！

因此這個翼弦前方四分之一的位置，就被我們定義為「氣動中心」(Aerodynamic Centre (AC))，是在進行飛機設計或其它各種計算分析時，我們所假定的作用力中心位置。比照升力係數與阻力係數，我們也來歸納個力矩係數的關係式。不過既然力矩不會隨攻角變化，因此其實力矩係數就是個常數：

\[ C_m = const. \]

最後補充一些小內容。其實實際製造的各種奇形怪狀翼型畢竟與純理論相較還是存在許多流場上的細節差異，因此若讀者有仔細閱讀本篇所參考的那份報告的話(至於本篇內文的圖表就沒有探討這麼細了)，就會發現其實每一個翼型的真實氣動中心位置是不一樣的，連同個翼型在不同雷諾數下的氣動中心位置都有差異！而那份文件其實都有分別做出兩個不同參考位置的力矩係數圖表，一個以四分之一翼弦為中心，一個以實際的氣動中心為中心；只不過兩圖表之間數據機本沒什麼起眼的差距。這告訴我們其實嚴格意義上的氣動中心和我們一般所簡單定義的四分之一弦位置並不相同，並且氣動中心的位置其實在不同條件下是會變化的；不過因為這兩者之間的差異實在真不是很大，因此一般通常簡單起見，人們大多還是直接假定四分之一翼弦位置處大約就是氣動中心所在位置。

延伸上面的補充內容，氣動中心其實在不同的情況下是會移動的，只不過通常這個變化太小，因此一般會直接忽略這方面的影響。但是有的時候這個移動量會相當大，以致人們無法忽略！比方在超音速情況下，氣動中心的位置就會在大約 50% 翼弦的位置，也就是翼弦的中央。這個巨大且無法忽略的變化，導致那些能夠超音速飛行的飛機往往會需要在姿態穩定和姿態控制上面下比較多功夫，因為次音速飛行和超音速飛行時的平衡位置存在相當大的差距。

為什麼要係數化？

不知有沒有讀者存在這樣的疑問：為什麼要使用係數呢？直接告訴我們機翼的升力多少、阻力多少，這樣不簡單純粹嗎？看升力係數多少、阻力係數多少，好像不符合一般人的直覺，倒不如直接告訴你升力多少牛、阻力多少牛；甚至於可能更多一般人熟悉的力單位也不是牛，而是公斤或噸。反正做實驗直接量出來的肯定也是力的大小，還要轉換計算一下才會變成係數，然後使用的人也同樣要轉換計算回來才會變成力。那麼使用係數的意義何在呢？為什麼科研領域都喜歡告訴你係數呢？

直接使用最終的力大小(或者最原始的力大小)，感覺好像比較直覺簡單，然而實際上其實比較複雜干擾！怎麼說呢？因為具體力的大小和太多因素有關了！比方說你要造一架飛機，看上的那個翼型有升力 100 牛，可是你的飛機需要 1000 牛，那麼你的機翼得造多大？是不是得先看看那個翼型在測試的時候用的是多大的機翼再轉換計算一下？這還是已經選定了翼型的情況下，要是還沒選定翼型呢？ A 翼型 50 牛、B 翼型 100 牛、C 翼型 10 牛，但是最後可能是 A 翼型用在你的飛機上升力最大！啊？因為三個翼型在試驗的時候可能用的面積不一樣、或者風洞吹的風速可能也不一樣。或者你朋友說他造了一個翼型比你現在用的升力數字更大，結果你拿來用之後卻發現結果並沒有比原本用的更好，才發現原來你朋友是放在水裡面測試的，水的密度大那當然作用力也大了！

所以其實可能和很多非工程學界的人想像的不同，係數化的意義其實就是在進行純粹化，降低複雜度。係數化(或者更有學問叫作「無因次化」)的目的就是排除其它非關鍵參數的具體量值，而只凸顯那最關鍵的特徵。你會發現在上面那些計算式和實驗數據圖表之下，各係數的差異與具體的空氣流速、空氣密度、和翼面積大小等沒有關係，而只與翼型的「形狀」有關係；也就是係數之間的比較能夠單純顯示出不同形狀設計之間的性能優劣，而最大程度排除其它不相干的因子。至於具體應用上能產生多少力？把你的實際應用條件套進去一算就知道了！

1. Reynolds Number

2. Airfoil

3. 螺旋槳 3：各種奇妙問題

4. Summary of Airfoil Data

5. 翼型系列 2：機翼流場現象

6. 翼型系列 1：機翼升力原理

螺旋槳 5：前拉或後推

Sat, 26 Jul 2025 17:58:32 +0800

相信在資訊發達的現代，讀者們大多曾見過一些長相比較怪異特別非主流的飛機造型，也許會注意到其中有些飛機的螺旋槳是放在飛機後面的，這是為什麼呢？螺旋槳放後面有什麼好處？又為什麼大部份飛機螺旋槳都放前面呢？

Figure 1. 使用前拉佈局的螺旋槳飛機 ^[1]

Figure 2. 使用後推佈局的螺旋槳飛機 ^[2]

其實螺旋槳放飛機前面或後面都是可以的，最常見的就是把螺旋槳放在飛機前面，這樣螺旋槳產生的動力就在機頭將飛機往前方拉動，因此這種配置就被叫作「前拉」式；相對的，螺旋槳放在飛機後面，產生的動力就將飛機往前方推動，因此這種配置就被叫作「後推」式。為什麼有些飛機採用前拉，而有些飛機採用後推呢？前拉與後推螺旋槳的主要差異在於性能的表現上。

Figure 3. 前拉佈局的螺旋槳氣流與飛機質心示意圖 ^[3]

Figure 4. 後推佈局的螺旋槳氣流與飛機質心示意圖 ^[4]

螺旋槳加速空氣因此會產生一股高速氣流，在一般常見的前拉式配置下正好直吹後方的機體，產生更多的阻力消耗 (因為阻力與氣流的速度平方成正比)；而若將螺旋槳佈置在機體後面，則正好避免了被氣流消耗而增加阻力的問題。雖然螺旋槳前方也會吸引氣流，這個氣流也同樣會吹拂機身而產生阻力，但如同在介紹螺旋槳噴流 ^[5] 時所解釋過的，前方吸氣的範圍比較大，且流速相對低得多，影響相對小得多。因此，採用螺旋槳後推佈局可以減少不必要的氣流阻力消耗，提高推進效率，能夠飛的更快，也能夠飛的更遠。這就是那些飛機之所以採用後推佈局的主要考量因素，可能也是後推佈局的唯一優點！

那麼既然如此，後推佈置方式看上去如此優秀，為什麼大部份的飛機都沒有採用後推式佈局呢？這就來看看後推佈局有哪些缺點或副作用了！

低速性能

不論是機翼的升力或者是舵面的工作效力都是直接和氣流的速度有關的，具體原理可以參考我曾經做過的機翼升力原理系列文章 ^[6] ^[7] ，翼面所產生的力大小與氣流速度的平方成正比，無論是升力或阻力皆同。因此當氣流速度愈低時，機翼產生的升力愈低，舵面產生的控制力道也愈低。也就是說在低速狀態時，飛機的操控能力會比較差，除此之外甚至於可能因為升力不足而無法將飛機舉升離地，而前拉式佈局正好(稍微的)改善了這個問題！在考量飛機飛行速度較低的情況下，前拉螺旋槳正好製造了一股強烈的高速氣流吹過後面的機翼與尾翼，使得即便在空速較低的情況下(當然低或高都是相對的)，操控性具有一定程度的保留而不至於完全失去控制，機翼也能在螺旋槳氣流的作用下得到更多的升力。而後推式螺旋槳在同樣低速狀態下的飛機控制能力就會比較差，甚至因為無法獲得足夠的升力而不能夠維持飛行。

簡單來說就是前拉式螺旋槳可以在(相對於後推式)更低一些的飛行速度下達到升空條件，也就是起飛距離更短些，進場降落的速度也更低些，而後推式螺旋槳則相較需要更長的起降距離與更高的進場速度；即便是在足以維持飛行的低速狀態下，前拉式螺旋槳可以保有一定程度的姿態控制能力，而後推式螺旋槳則相對操控性較差，甚至可能會失去對飛機姿態的操控能力。

機翼佈局

對於飛機來說，發動機是挺重的，尤其特別對於輕型小型飛機而言。以前拉式佈局來說，發動機往機頭一放(因為機械結構的關係，發動機通常都得和螺旋槳放一起)，整個飛機的重心就被往前拉了(參考上圖 Figure 3)。這樣的重心位置可正好適合最傳統的尾翼式機翼佈局，將尾翼設計在長長機身的尾端。正好因為力臂足夠長，因此尾翼並不需要太大的面積就能夠提供足夠的穩定性與操控性。

那如果是後推佈局呢？螺旋槳和發動機往後面一擺，得，整個飛機的重心往後拉了(參考上圖 Figure 4)！因為飛機的重心相當靠後，機體後面力臂過短，所以尾翼的面積必須得要造的相當大，無端增加阻力消耗。此外可能比這個更大的問題是，螺旋槳擺在那裡礙事，尾翼要怎麼放呢？這就是為什麼我們通常見到的後推螺旋槳飛機通常都會採用鴨翼佈局的緣故。因為飛機的重心太過靠後，後面沒有足夠的機身距離來作為穩定控制的力臂，相反的重心前方的機身長度夠長，反而非常適合將穩定翼放在機身前方，因此特別適合採用鴨翼佈局。鴨式佈局本身具有一些缺點，比方說設計與使用上的難度與限制比較多，極限條件的操控性不如尾翼佈局好等等。嚴格說起來這其實是屬於機翼佈局的缺點而非螺旋槳後置的缺點，然而因為前面描述過的原因使得使用螺旋槳後推佈局的飛機往往不得不搭配採用鴨式佈局，使得這些缺點也默默連結成了後推佈局的缺點。

Tip	什麼是鴨式佈局？這是飛機的空氣動力穩定性佈局的一種型式。關於氣動穩定性的部份實非三言兩語能夠說得清，也超出了以螺旋槳為主題的內容範圍，因此這裡只對於名詞作簡單的解釋。主機翼只提供飛機所需要的升力，而飛機的穩定性則需要專職穩定作用的小翼來提供。一般最常見的穩定翼都是放在飛機的尾端，因此被稱為「尾翼」，這種佈局就稱為「尾翼佈局」；相對的，將穩定翼放在飛機前端的情況就被稱為「前翼」，這種佈局就稱為「前翼佈局」。由於採用前翼佈局的長相看著和鴨子的神韻有些相像，因此這種佈局又被稱為「鴨式佈局」，因而前翼也就同樣得到了「鴨翼」這樣的稱呼。

那麼如果我就是情有獨鍾傳統尾翼佈局，有沒有辦法在使用後推螺旋槳的情況下仍然使用尾翼佈局呢？答案是這樣也不是不行！一般通常有兩種狀況或方法可以在後推佈局的情況下使用尾翼佈局。首先是當飛機的體型足夠大時，螺旋槳與發動機佈局和機翼佈局兩者的連結性就能脫勾，例如下圖(Figure 5) B-36 轟炸機就屬於這樣的例子。而若飛機體型嬌小，還只有單螺旋槳，還要堅持使用尾翼佈局，那就只能用第二種方法了。加幾根延長結構去在空間上繞過螺旋槳的阻礙，然後將尾翼放在更後面的位置，例如下圖(Figure 6) XP-54 戰鬥機就是這樣的例子。當然這第二種做法會產生額外的副作用，如重量增加、額外的阻力和干擾等，至於其副作用帶來的劣性影響是否值得划算？就得看計算的結果以及設計者的權衡了！

Figure 5. 後推螺旋槳設計但仍採用常規機翼佈局的 B-36 轟炸機 ^[8]

Figure 6. 後推螺旋槳設計但仍採用常規機翼佈局的 XP-54 戰鬥機 ^[9]

當然鴨式佈局也不是都是缺點，它也是有好處的。這裡不詳細展開關於機翼佈局的內容，但總結摘要來說，鴨式佈局雖然在極限狀態下的控制能力較差，但其系統內耗較少，整體空氣動力效率佳，簡單說就是能讓飛機飛的更快、更省、更遠。所以後推式螺旋槳飛機也不盡然都是被逼迫著勉為其難去使用鴨翼佈局的。鴨翼佈局和後推螺旋槳兩者的優點不謀而合，對於速度和航程都具有正面的作用，因此往往是自然而然的，兩者通常就這麼互相搭配一起並同時出現在一架飛機上，形成一種奇妙的合作關係！

起落架長度

螺旋槳後置的一項缺點是通常會需要更長的起落架。由於起落架需要承載飛機在著陸時候的衝擊力，對於緩衝和結構的承受力都有一定程度的要求。如果不考慮其他因素而只考慮起落架本身的話，當然粗粗短短的起落架是最容易能扛住的，細長的起落架就會給相關機構的設計帶來難度和困擾。然而螺旋槳後置的方案卻往往會比前置方案需要更長的起落架！

因為後置的螺旋槳通常比前置的更容易敲擊到地面，因此需要把飛機架離地面更遠才能夠有效防止螺旋槳觸地受損。那麼為什麼放後面的螺旋槳更容易敲到地面呢？因為不論是在起飛離地還是降落觸地的時候，飛機往往都是拉抬機頭的姿勢，頂多是幾乎持平 (一般絕大部份正常情況是沒有低頭離地或落地的)。所以前置的螺旋槳可以被舉的更高而離地面更遠，反而後置螺旋槳就有點危險了，會距離地面更近！同樣的道理，前置螺旋槳可以搭配前三點起落架(例如 Figure 7)，也可以搭配後三點起落架(例如 Figure 8)。 (因此古時候的飛機都喜歡採用後三點起落架，因為簡單又節省； 當然這裡說的是指對於設計製造而言，而不是對於在地面上駕駛它的人而言！) 但是採用後置螺旋槳的顯然就不能夠搭配後三點起落架了，只能夠使用前三點；並且在後面主起落架必須把機體架的離地面夠高的情況下，前起落架往往得再架的更高，才不至於讓機頭下墜，例如 J7W1 震電戰鬥機就是相當鮮明的例子(Figure 9)。

當然除了把起落架弄長之外其實還有另一個解決方法，那就是限制螺旋槳的尺寸，不要用那麼大的螺旋槳，例如下圖(Figure 10)的 Velocity XL 就沒有像震電戰鬥機那樣誇張長的起落架。只不過採用小尺寸螺旋槳的副作用就是以犧牲螺旋槳的效率來作為代價的(具體原理往後再談)。

Figure 7. 採用前三點式起落架的 P-39 戰鬥機 ^[10]

Figure 8. 採用後三點式起落架的 FW-190 戰鬥機 ^[11]

Figure 9. 採用後推螺旋槳設計的 J7W1 戰鬥機，注意其起落架特別是前起落架的長度 ^[12]

Figure 10. 採用後推螺旋槳設計的 Velocity-XL 小飛機，起落架長度在一般通常的範圍內 ^[13]

跳傘逃生

螺旋槳放後面還有最後一項缺點，那就是不利於跳傘逃生！

當飛機損壞或在戰鬥中被擊傷而駕駛員欲棄機逃生的時候，拉開駕駛艙蓋往外一跳，得，等待你的就是在後面可能仍在高速轉動的螺旋槳切刀！當然從描述來看就能知道這項缺點主要體現在軍用戰鬥機上面，至於如果是民用飛機或雙發動機以上的軍用飛機則無此問題。而在歷史上採用後推螺旋槳的戰鬥機都同樣面臨駕駛員難以跳傘逃生的問題，往往需要搭配螺旋槳爆破裝置或彈射式逃生座椅來解決這個問題；或者讓駕駛員懷抱著與飛機共存亡的使命踏進駕駛艙！

總結

螺旋槳飛機採用前拉式或後推式動力佈局，在中、小型飛機，特別是單發動機的小飛機上面的影響差異相當大，也是在此前提下更加具有討論價值；至於在中、大型等多發動機的飛機上，採用前拉或後推的影響差異較小。

採用後推螺旋槳的好處是動力系統效率較好，使得速度較快、航程較遠，特別是在搭配鴨式機翼佈局的情況下能夠更進一步放大前述的優點！缺點則是起降距離較長，起飛與進場速度較高，以及低速下的飛機控制能力較差，不能進行高攻角機動動作(在不考慮現代飛控電腦干預下的靜不穩定設計條件下)，並且起落架的設計佈置和耐用性的困擾較多，以及不利於跳傘逃生等。雖然說採用前拉與後推動力佈局各有優缺點，但是以結果論，當今絕大部份小型飛機都採用前拉式動力配置的現實已經告訴了我們，前拉式螺旋槳在大多情況下是更加廣泛適用的選擇。

把 C++ 程式碼當直譯腳本執行

Fri, 25 Jul 2025 22:48:10 +0800

這次分享一個程式小技巧，能把 C++ 程式碼檔案當成腳本來執行，或許在合適的情況下會挺好用的喔！

有時候我們就是會有一些瑣碎的事情需要即時做個小工具來處理。我們通常不會太苛求這種工具的功能完整嚴謹與全面的覆蓋性，因為作為使用者兼設計師的我們可能是隨時監看並能依據當下條件即時調整修改程式的。對於計算效能多半也是無所謂的態度，因為對於或許是一次性的工具來說，通常使用更少的時間與消耗更少的頭腦精力去把東西製造出來的效益會遠大於仔細推敲打磨它。這時候我們通常就會傾向使用腳本語言來進行這些工作，比如我自己就經常寫些很簡單的 shell script，稍微複雜困難一點的工作就寫個 Python 來處理。

但是吧，有些工作使用這些常見的腳本語言來做就是存在一些不容易。可能雖然工作是一次性的，但資料量相當龐大，也不是真的這麼不在意直譯程式的效能；可能是有一些底層的資料格式需要分析處理，例如位元組、無號定長整數的計算處理等，使用 C/C++ 真的反而就是比較簡單方便；也可能其實當下流行的腳本語言並非沒有能力去實現出這些功能，只是因為個人學習鑽研道行實在不足。無論如何，對於一個數十年與 C/C++ 日夜相伴的程序員來說，有時候就是會有想要使用 C++ 去製做這些工具的想法。

那麼做就做吧，產品程式都能造出來了，製做個人的工具程式有什麼困擾呢？通常的糾結也許就在於這種編譯式的語言所產生出來或所需要依賴的檔案數量較多，對於不是以軟體專案本身當主角，而是在周邊小工具的用途上當配角去服務其它檔案的話，在檔案的儲存、管理、和命名等事情上就會帶來比較大的龐雜感；特別是對於慣用 IDE 工具來進行程式開發的人來說，身為一個小小龍套配角的工具程式其檔案數量可能會更加驚人！

使用腳本編譯執行

至此對於本篇所探討的 C++ 程式的使用情境已經明瞭了，就是以簡單小工具為定位，以最少的檔案管理負擔為訴求，為此目的可以容許對於執行效能的一定程度下降為代價。

從前我的做法是就在 C++ 程式碼旁邊建立一個 shell script 檔案，用來編譯並執行旁邊的程式碼檔。不使用 Automake 或 CMake 這些龐大複雜的建置系統，當然更不可能使用 IDE 專案。就只有一個簡單的腳本，不檢查檔案時間戳也不產生中間檔，每次執行時就是從頭全部重新編譯。當然以配角小工具的用途來說一般程式碼沒有什麼太大的規模，程式碼的檔案數量也就只有一個，每次執行時都重編譯過一次也並不會消耗什麼有感的時間；而其實這就是把 C++ 拿來當直譯腳本語言使用的概念。

在這樣的使用方式下，檔案的數量減少到只剩下 2 到 3 個，分別是主要的 C++ 程式碼，用來編譯並執行程式的腳本，以及使用後可留可刪的執行檔。雖然已經只剩下 2、3 個檔案，但是終究還是複數，與只需要單一一個檔案就能做事的真正腳本語言相較還是多了些負擔。那麼能不能夠將檔案再進一步縮減到只剩下一個呢？

要進一步精減檔案數量，首先可以排除掉的就是執行檔了。既然已經寫了個腳本去做編譯，順便編譯完後立刻執行，那麼稍微再多寫一些步驟就能夠在執行完成後將產生的執行檔給刪除，做法並不困難。因此真正的挑戰在於如何將 C++ 程式碼檔案與建置腳本檔案給二合一，而這就是本文真正要探討的技巧主題了……

利用 Preprocessor

將兩個檔案合併為一個檔案的問題在於，兩個檔案內容的格式規格並不相同，一個是 C++ 而另一個是 shell script。要將它們合併在一起，就必然要想個方法讓同一個檔案既能夠被 C++ 編譯器正常處理，也能被 shell 正常解析，讓檔案內的兩個部份互相不干預對方。關於腳本的部份倒好處理，反正 shell 是一行一行分析執行，所以只要把腳本的部份寫在檔案開頭，然後在腳本命令最後放一個 exit 命令結束並離開，那麼再往下的內容長成什麼鬼樣子(站在 shell parser 的角度)就完全不造成影響了！所以真正的問題在於如何讓 C++ 編譯器去忽略掉檔案開頭的那些腳本命令？

這裡採用的方法是利用 C++ 前置處理器的識別符號「#」。剛好在 shell script 裡面這個井字號是註解符號，所以任何 C++ 前置處理命令在 shell 裡面都會被忽略掉，因此可以放心使用。只剩下腳本開頭的 Shebang (也就是通常在腳本開頭出現的那個「#!」)會在 C++ 編譯的時候導致錯誤，好在當代的 Linux 環境大部份在沒有 Shebang 的情況下也是把檔案內容當成 shell 命令在處理，因此這裡就放心的直接捨棄掉正規 shell script 在檔案開頭的 Shebang 了。

按上述想法所產生的範例程式如下：

#ifdef UNDEF    // 從這裡開始的內容會被 C++ 編譯器所忽略
ap=$(mktemp -u)
c++ -Wall -o $ap "$0" && $ap $@
rc=$?
test -f $ap && rm $ap
exit $rc        #  腳本命令到這裡被強制跳離，因此以下所有檔案內容不受 shell 解析處理
#endif          // 直到此之前的內容會被 C++ 編譯器所忽略
#include <stdio.h>

int main(int argc, char *argv[])
{
    printf("Running CPP file as script...\n");

    printf("Arguments (argc=%d):\n", argc);
    for(int i = 0; i < argc; ++i)
        printf("  argv[%d]: \"%s\"\n", i, argv[i]);

    int rc = 7;
    printf("Return the result code: %d\n", rc);
    return rc;
}

這樣就可以直接把 C++ 程式碼檔案當成腳本來執行(當然檔案屬性需要設定執行權限)：

./cppscript-use-preprocessor.cpp qui tollis peccata mundi; echo "RC=$?"

上面的執行命令最終產生了如下的結果，可以注意到我把程式的啟動參數傳遞以及返回值的傳遞都處理妥當了：

Running CPP file as script...
Arguments (argc=5):
  argv[0]: "/tmp/tmp.KU6vOCid49"
  argv[1]: "qui"
  argv[2]: "tollis"
  argv[3]: "peccata"
  argv[4]: "mundi"
Return the result code: 7
RC=7

這樣其實就已經達到了一開始所要的目的，將全部檔案整合為一個檔案，把 C++ 當直譯腳本來用。當然上面的範例設想的還是比較多的，如果你自己使用情況下並不需要取得程式回傳值，或者不需要傳輸啟動參數，或者甚至可以直接指定一個固定的執行檔名稱而不是像上面隨機產生一個暫時檔，那麼有關建置與執行的命令還可以再刪減的更加精簡。

利用單行註解

理論上使用上面的方法已經達成了將程式碼與腳本合併只剩一個檔案，並且能把 C++ 檔案當直譯程式來執行的目的。只不過對於檔案開頭好多行的腳本內容還是覺得有些礙眼，特別是雖然那些命令已經被包含在 #ifdef 裡面，但可能有些文字編輯器還是會嘗試去分析裡面的內容，而因為這些內容都不是合法的 C++ 語法，因此雖然實際不會產生錯誤，但在編寫 C++ 的時候可能會顯示出許多較為「醒目」的語法著色顯示。於是我好奇有沒有能人還有更好的想法？結果一查欸還真有！ ^[1]

其中一種方式就是利用 C++ 的單行註解符號「//」。而斜線「/」同時也是路徑的分隔符號，單獨的或起頭的斜線則在 POSIX 相容系統上表示根目錄，而兩個連著的斜線路徑分隔符其實等同於只有一個。因此檔案的起頭必須指定一個絕對路徑，也就是說檔案一開始的第一個命令就是要執行一支程式。上面參考網站的內容直接使用絕對路徑執行編譯器，然而因為我在編譯前還想先設定變數內容，因此無法像他這樣簡單的直接呼叫命令。我的做法是將第一個命令給虛化，它不需要做實事，我只不過是利用它的路徑起頭符號將整行文字被 C++ 編譯器判定為註解而已。因此我選擇首先執行 true 命令，基本等於沒有任何實際效果，然後在分號後面再去執行我真正要執行的工作。

按照這樣的想法，我將前面的那個範例修改如下 (至於命令的執行和輸出的結果就不貼了，反正是一樣的)：

//bin/true; ap=$(mktemp -u); (c++ -Wall -o $ap "$0" && $ap $@); rc=$?; (test -f $ap && rm $ap); exit $rc
#include <stdio.h>

int main(int argc, char *argv[])
{
    ......
}

就這樣把全部的命令塞在一行 C++ 註解裡面，看著更加清爽也少了視覺干擾。只不過缺點也很明顯，這一行文字挺長的，如果編譯的命令再複雜一點，比如說連結一些程式庫、加入更多編譯巨集等，那長度又會更加延伸；不過相對的，如果你的使用並不需要回傳值、程式參數這些東西，甚至也不想刪除編譯出來的執行檔的話，那麼這個寫法就會變得相當簡潔，相當合適！例如像下面這樣，看是不是好多了：

//bin/c++ -Wall -o $PWD/example "$0" && $PWD/example $@
#include <stdio.h>

int main(int argc, char *argv[])
{
    ......
}

利用多行註解

前一個做法的缺點就是在編譯參數較多的時候，檔案第一行會變得很長，有些人可能覺得無所謂，有些人可能覺得受不了。那如果無法忍受過長的文字行的話，就還是得把命令寫成多行來表達，按照延續的思路，我們可以用 C++ 的多行註解來處理這樣的需求。其巧思之處在於 C++ 多行註解的開頭「/*」，在 shell 下的意義就是根目錄下的任一個檔案或資料匣，那麼我就取用其中的隨便哪一個，然後再返回上一層，看兜了一圈不就等於又回來了！

按此思路修改前面範例，則為：

/*/../bin/true
ap=$(mktemp -u)
c++ -Wall -o $ap "$0" && $ap $@
rc=$?
test -f $ap && rm $ap
exit $rc
*/
#include <stdio.h>

int main(int argc, char *argv[])
{
    ......
}

這樣就兼顧了可以在合理的版面空間內容納較多較複雜的命令，同時又把命令全塞進 C++ 註解內減少在編寫程式時的干擾，幾乎完美解決了所有問題。因此最終，在想要把 C++ 程式碼當成直譯腳本來使用的需求下，我推薦最後面介紹的這兩種使用註解的寫法，在編譯與執行命令較為簡單簡潔時推薦使用單行註解方式，而在相關命令比較繁多時則推薦使用多行註解的方式。

1. Run C or C++ file as a script

螺旋槳 4：奇妙問題的各種對策

Mon, 21 Jul 2025 01:29:12 +0800

前篇 ^[1] 介紹了那些會發生在螺旋槳上面的各種奇妙現象，它們都對飛機的性能和操控性帶來許多程度不等的壞處。那麼本篇就來看看人們為了改善這些問題都做了什麼樣的努力與巧思呢？

減小螺旋槳的尺寸和質量

Figure 1. 直昇機巨大的主旋翼產生了同樣巨大的反扭矩，而尾部尾旋翼便是為了對抗平衡此扭矩而存在 ^[2]

縮減螺旋槳的尺寸和質量可以直接減少反力矩，和陀螺效應所帶來的問題。這就是為什麼人們在製造螺旋槳的時候總是會儘量在結構強度範圍內去輕量化螺旋槳的原因了，同樣也是為什麼旋轉發動機 ^[3] 誕生沒多久就被紛紛棄用的主要原因之一！不過關於螺旋槳的尺寸部份就有些兩難，螺旋槳是尺寸愈大效能愈好(以後會再分析解釋這部份)，然而過大的螺旋槳卻會對飛機造成更多平衡上的問題挑戰；過小的螺旋槳則雖然平衡的問題沒有了，但同樣會受到推進效率不足、推力不足的問題困擾。因此實際對於螺旋槳大小的問題，需要通盤考量並折衷取捨。那如果在有些應用上這個尺寸、質量降不下來呢，比方說直昇機？直昇機的主旋翼省不下來，就必須得造那麼大才夠用怎麼辦？這就是為什麼直昇機的姿態控制與運動行為更加複雜，並且需要額外一個小尾旋翼來平衡力矩的原因了！

控制舵配平

Figure 2. 飛機控制舵面上的配平片 ^[4]

其實飛機的舵面控制系統中本來就存在一種微調校正機制，也就是配平。如果近距離觀察飛機的操作舵面(最好是那種傳統鋼纜控制的飛機，而不是線傳飛控電子控制的飛機)，就能發現機翼上的舵片它自己還有一個更小的舵片(如圖 Figure 2 所示)，有種套娃的樣子。

這種被稱為「配平片」的東西最初的目的是用來修正誤差用的。怎麼說呢？實際製造的飛機不可能如同理論圖紙那般的完美無缺，多少帶點誤差，多少帶點不對稱。因此當你放手讓操縱杆回中的時候，理論上飛機應該要穩穩的保持歸正姿態飛行，然而實際上通常飛機會稍微歪一邊(歪哪邊就不確定了)，而不能保持直線飛行。這時就可以透過人為的調整配平去微調各舵面的置中位置(Natural Position)，否則若沒有配平的存在，那麼駕駛員就得一直施力壓著桿子在某個狀態，才能夠維持飛機的姿態平穩。當然一般人可能少有飛機的駕駛經驗，那我就用汽車來做類比解釋。飛機的配平就像是汽車的四輪定位校正，如果讀者有駕駛過那種久未妥善維護保養，車輪校正早已跑偏十萬八千里的那種車輛的經驗，那麼應該就能夠明白飛機配平的意義與作用了。缺乏車輪校正(妥善配平)的車輛(飛機)仍然能夠正常駕駛，只不過駕駛起來可能會有點辛苦！駕駛員必須永遠握緊方向盤(操縱杆)並時刻專心保持車輛(飛機)的行進動態，才能夠平穩前進。

既然飛機上已經存在控制面配平的機制，那麼螺旋槳本身所造成的一些不對稱、不平衡的力能不能也算做是飛機本身的不對稱誤差，然後使用配平來把它修正過來呢？當然可以！於是舵面的配平就成為校正螺旋槳偏向力的一種常用手段。不過這只能夠用來對付那種會持續存在的穩定作用力，比方說巡航狀態下的螺旋槳扭矩，巡航攻角下的偏航力矩等等。至於其它情況下的飛行狀態，乃至於推拉桿的瞬間才會出現的臨時作用力等等就沒有辦法了，應對這些動態的不平衡力還是有賴於依靠熟練飛行員的「手感」去做出類似於肌肉記憶的適當補償動作。

此外舵面配平也不是萬靈丹，其也是存在自身的限制和代價。比如說它只能夠在小幅度範圍內去做平衡對抗，對於過大的作用力則可能還是力有未逮。此外配平的原理其實就相當於在你不推拉桿的情況下去自動幫你推拉桿到一定的角度，也就是說它實際上是透過施力給舵面去偏轉角度來產生平衡對抗的作用力，也就是說它會產生額外的阻力。

對轉螺旋槳

Figure 3. 使用對轉螺旋槳設計的 P-38 ^[5]

Figure 4. 對轉螺旋槳 ^[6]

如果飛機上有偶數數量的螺旋槳的話，那麼其實可以讓飛機對稱兩邊的螺旋槳互相反向旋轉，如上圖(Figure 4)所示，這種方案就稱為「對轉螺旋槳」，其中著名的 P-38 戰鬥機就是採用這樣的設計方案。如此簡單的讓兩邊螺旋槳往相反方向旋轉，就可以直接對消掉絕大部份不對稱力，包括扭矩、側滑、氣旋、乃至陀螺效應等等，幾乎所有的不平衡力都能被這樣簡單的設計給對消掉！

這方案看似挺美好，但也是存在一定程度的副作用。首先是單引擎單螺旋槳飛機便無法採用對轉的方案，其次是這樣的設計規劃會給製造裝配和維修保養帶來一定程度的成本負擔。因為對轉螺旋槳對應的兩臺發動機旋轉方向不一樣，從螺旋槳到引擎曲軸的許多零件都會需要區分左邊版本與右邊版本，不論是對於製造的成本，或者是拆解維護的工時，或者是零件備料的倉儲負擔，都會造成一定程度的加重。因此 P-38 外銷給法國和英國的版本就被要求全部改成一律右旋的版本。

氣流導正葉片

Figure 5. 現代渦扇發動機結構剖視圖，注意紅色指標處的柵欄狀結構，兼俱導正風扇氣旋，以及作為外殼支撐結構的作用 ^[7]

Figure 6. 被稱為循環扇的電風扇類型，注意其正面密集的幅條，在兼任結構支撐與防範異物的功能之外，其相當的深寬正是為了導正風扇氣旋的作用 ^[8]

螺旋槳旋轉所產生的氣旋，除了會產生偏轉飛機的力之外還會降低推進效率，因此如果能夠將螺旋槳後面的氣流導正過來的話，就可以同時解決這兩個問題。其中一種方案就是直接安裝氣流導正葉片。氣流經過導正之後消除了氣旋，成為更加筆直強勁的氣流，提高推進效率之外也解決了氣旋帶來的不平衡力。

這個方案罕見在螺旋槳飛機上看到，但其實在某些其他應用用途上則可能相當常見，例如在與螺旋槳一樣原理的渦輪風扇發動機，風扇後面就有排列一整圈的這種導氣葉片，如上圖(Figure 5)所示。其實要深究的話，渦輪發動機裡面的每一級定子葉片也擔負了相同的作用。另外還有一種同樣的設計更加容易在日常生活中見到，那就是一般被稱為「循環扇」的電風扇(Figure 6)，其風扇前面輻射狀的厚重防護網就是被刻意造成如同導氣葉片的形狀，擔負著導正風扇氣旋的作用，從而使得能把空氣吹的更遠。

然而這個方案在常見的「飛機螺旋槳」這個用途上卻往往窒礙難行，其原因與後面會提到的螺旋槳圍殼(涵道)相同，因為螺旋一般尺寸較大，採用這些設計所帶來的好處不一定能抵過其多出來的結構重量和阻力。

同軸反轉螺旋槳

Figure 7. 採用同軸反轉螺旋槳的特別款式野馬式戰鬥機，注意它有兩具一前一後緊靠著的螺旋槳 ^[9]

Figure 8. 採用同軸反轉螺旋槳的特別款式噴火式戰鬥機，注意它兩具螺旋槳的旋轉方向是相反的 ^[9]

Figure 9. 現代經常會出現在電視新聞畫面的 Tu-95 轟炸機同樣設計了同軸反轉螺旋槳 ^[9]

Figure 10. Ka-50 直昇機使用了同軸反轉的主旋翼，無需面對氣旋與扭矩等問題，因此注意到在它身上並沒有用一般直昇機上會看到的尾旋翼！ ^[10]

Figure 11. 同軸反轉螺旋槳 ^[9]

顧名思義，同軸反轉就是用兩隻螺旋槳放在同一根軸上，並且各以相反的方向旋轉，如圖(Figure 11)所示。

同樣使用一對旋轉方向相反的螺旋槳，但不同於對轉螺旋槳只是簡單的將兩具螺旋槳放在各自位置上，同軸反轉螺旋槳顯得更加激進，將兩具螺旋槳安裝於幾乎要疊在一起的空間位置上。因為兩槳共軸，因此被稱為同軸反轉螺旋槳。與對轉螺旋槳相同，同軸反轉螺旋槳能夠對消所有的不平衡力如扭矩、側滑、與氣旋等，因此採用這種設計的直昇機如 Ka-50 (Figure 10)就不再需要使用尾旋翼來作為平衡。除此之外還比對轉螺旋槳多了一個效果：它還能對消螺旋槳的尾部氣旋！因此同軸反轉螺旋槳的推進效率更高，即便因此多出了齒輪結構等重量，那些採用了同軸反轉螺旋槳設計或改裝的飛機，往往能夠跑出比其傳統螺旋槳版本更快的速度。

既然這種方案這麼好，那為什麼沒有被廣泛大量採用呢？顯然也是存在缺點的！首當其衝就是更加複雜和笨重的驅動結構，使得不管設計製造還是維護保休成本都更加高昂。另外這種螺旋槳還有一個特色：非常吵！這是因為距離如此接近的兩個螺旋槳，葉片會週期性的非常靠近到幾乎重疊，產生相當強烈的空氣擾動與擠壓效應，因此產生一個相當強烈的壓力突波，也就是聲音。這就是為什麼所有採用同軸反轉螺旋槳的飛機都相當吵的原因，甚至於傳言 Tu-95 轟炸機飛在大西洋上的聲紋還能被水底下的潛水艇聲納給捕捉到呢！ (至於存在同樣結構特徵的渦輪發動機，那一大堆的動子、定子葉片，難道就不吵嗎？ 其實渦輪發動機的音量也是真的大，只不過多了外殼的消音隔絕作用， 相比之下沒有曝露在外的同軸反轉螺旋槳那樣吵罷了！)

不對稱設計

其實如果有機會近距離觀察單螺旋槳飛機或者其之精確圖紙，或者是有在玩遙控飛機的人，可能會發現許多螺旋槳及發動機的安裝並不是對稱的，而是偏了一個方向，這就是為了螺旋槳不平衡作用力所做的補償。

Figure 12. 單螺旋槳飛機的螺旋槳和引擎往往是微幅右偏轉安裝的，有時可能連尾舵也不是置中對正的 ^[11]

若不考慮機動動作過程的暫時性不平衡，而只考量大多時候穩定飛行時的不平衡狀態的話，那麼會發現螺旋槳可能成份最大的綜合作用是給飛機一個左偏的力矩。在只考量受螺旋槳影響最大的單螺旋槳、單發動機，且螺旋槳放在飛機頭的最常見配置下，那麼如果把螺旋槳(包含整個發動機)稍微向右轉一個小角度，這樣就能用不對稱的推力線產生的右偏力矩去平衡掉螺旋槳造成的左偏力矩，如上圖(Figure 12)所示。此外在這類飛機上通常也會發現發動機不只角度偏右安裝，還會往下偏轉一個角度。向下偏轉推力線同樣也是為了平衡的作用，只不過對付的不是螺旋槳所造成的不平衡，而是平衡掉尾翼穩定系統在速度愈快的情況下會使機頭飄浮起來的作用力矩而做的補償。

既然發動機都能夠不對稱安裝了，那其它平衡舵能不能如法炮製？能！於是有些飛機的垂直尾舵也不是對稱設計的，而是整個舵面向左一個角度安裝的，如上圖(Figure 12)所示。不過這裡補充一點，上圖為了示意的緣故所以畫了比較大的有點誇張的偏轉角度，然而實際上發動機安裝偏角與舵面的安裝偏角通常只有約 0.X 度到 2 度左右的範圍而已，若不仔細觀察還不是很容易發現的，不會像示意圖這樣的誇張明顯！

Figure 13. 在不對稱設計上堪屬登峰造極的作品：BV-141 ^[12]

「原來造飛機可以不用完全對稱啊？！」「原來可以不對稱來解決問題啊？！」思路一下子打開之後，莫名的對稱強迫症治好了之後，設計也就越發自由奔放。其中當屬最為登峰造極的作品大概就是德國的 BV 141 了(Figure 13)，它的外型似乎無聲的在訴說：「飛機本不應該對稱，因為螺旋槳本就不是對稱的東西！」 (其實 BV 141 這樣不對稱的造型雖然確實包含了，但並不完完全全僅只是因為螺旋槳的因素， 其中還有為了方便人員觀察的目的！) BV 141 的造型看似怪異，然而據聞駕駛過它的飛行員描述其駕駛之感受相當良好，流暢自然，與其外表帶給人的突兀感受完全相反。只不過這種不對稱的設計思路後來並沒有再被進一步發揚光大，因為這種根本不對稱的設計主要就是來源於螺旋槳的不對稱特性造成，而眾所皆知，噴射引擎佔據時代主角位置之後，就沒什麼動機再去刁鑽「單螺旋槳在中大型飛行器的應用」這項主題了！

槳葉造型

螺旋槳的槳葉尖端會發生氣流翻越所產生的誘導流，導致螺旋槳效率降低。這個問題比較不一樣，它不像其它那些問題會導致不平衡、不對稱的作用力去干擾飛機的穩定與操控，純純就是降低螺旋槳的氣動效能而已。

Figure 14. 飛機機翼尖端的小翼裝置 ^[13]

對於翼尖渦流，在現代民航客機上常可見到的翼尖裝置(如圖 Figure 14)就是用來改善這個問題的。其作用原理就是阻礙氣流的翻越，或使渦流發生的位置更加遠離機翼。然而很不幸的，螺旋槳的槳葉沒有辦法採用這樣的翼尖裝置方案。因為螺旋槳的轉速實在太快，在滿功率運轉時往往尖端能達到或超越音速，加上強大的離心力作用，大概沒有什麼裝置能夠在這種情況下簡單扛得住；或者就算有，大概也免不了振動和平衡的問題。因此翼尖裝置的方案沒辦法簡單的直接應用在螺旋槳上面。

既然這個渦流是從機翼尖產生的，那如果我把機翼的尖端做的小一點，是不是就能讓渦流也小一點，改善渦流影響的問題呢？欸雖然聽起來有那麼一點「啊～這也能行？！」的驚嘆，然而實際上這麼做還真的能行！

Figure 15. 追求極高空氣動力效率的滑翔機往往具有相當誇張的機翼展弦比 ^[14]

所以那些講究機翼效率的飛機往往都喜歡把機翼造的細細長長的，比如像上圖(Figure 15)那樣的滑翔機。你可以這麼理解，把機翼造的長一點，可以讓渦流產生的位置遠離機翼核心區域，因此能夠改善渦流問題；或者也可以理解為將機翼造得細，那麼尖端的尺寸(相比於整片機翼的比例)就縮小了，也能減小渦流強度從而改善問題；總之就是展弦比(也就是機翼的「展」、和「弦」的比值，或者也可以理解為長寬比)愈大，愈能夠削減翼尖渦旋對整個機翼的影響。而這也就是為什麼飛機螺旋槳的槳葉都喜歡造的細細長長的同樣原因。

單純的將機翼(比例上)造的細了確實可以改善尖端渦流的問題，問題是機翼的面積也小了，升力(推力)不夠怎麼辦呢？於是有些更加講究登峰造極的飛機就會給機翼的形狀玩起花活兒！既然愈靠近渦旋的部份受影響愈大，愈遠裡渦旋的部份受影響愈小，那我能不能夠將機翼按照受渦流影響的程度來不等比的縮減機翼的弦寬呢？可以！這就是機翼教科書上面所描述的橢圓形機翼，既擁有超小尺寸翼尖，也不至於讓機翼面積變太小，例如經典的噴火式戰鬥機(Figure 16)就是將機翼造成這種形狀。當然將機翼這麼造的話可能會苦了製造它的勞工們，也會增加建造的成本和時間，於是也有一些稍微變化的沒有橢圓形那麼完美但設計製造比較經濟方便的變形，例如 U-2 (Figure 17)採用了梯形的設計，或例如零式戰鬥機(Figure 18)在梯形翼的基礎之上加上了半圓形的翼尖。

Figure 16. 採用橢圓形機翼的噴火式戰機 ^[15]

Figure 17. 採用梯形機翼的 U-2 偵察機 ^[16]

Figure 18. 零式戰鬥機採用以梯形機翼為基礎加上半圓形翼尖的造型 ^[17]

螺旋槳槳葉同機翼，那麼在了解了機翼形狀的設計原理之後，是不是就突然明白為什麼飛機螺旋槳的槳葉都長成這些形狀(Figure 19)的原因了呢？螺旋槳的槳葉都造的細細長長，並且大部份喜歡在尖端部位做橢圓漸收或者半圓收口。至於根部的縮窄主要是為了結構強度考量的因素，在愈靠近根部的地方愈是設計成接近圓柱的截面形狀而使得其投影形狀看起來會變窄，另一方面也是因為槳葉在靠近根部的位置其移動速度已經很慢了，對於推進的作用已經不大。

Figure 19. 空氣動力效用最佳化設計之下的螺旋槳葉片造型

涵道圍殼

依靠槳葉的形狀可以相當程度的消減尖端渦流所產生的影響，但並不能夠完全消滅之，如果要得到更好的渦流應對對策的話，還是需要在端面去想辦法破壞或限制渦流的發生。前面說過螺旋槳本身因為高速旋轉的關係，實在難以在槳葉上面做什麼額外的裝置；但是如果換個思路，如果我的葉尖裝置不放在槳葉上呢？如果把阻礙尖端渦流產生的屏障放在螺旋槳的外面，直接環繞一圈固定在那裡，得，這就是「涵道螺旋槳」(Ducted Propeller)，或者「涵道風扇」(Ducted Fan)，端看應用領域一般習慣稱呼為螺旋槳或風扇而定。

因為有這麼一圈環形護圈的存在解決了尖端渦流的問題，因此採用了涵道設計的螺旋槳槳葉形狀通常就比較不受太多限制，可以寬大一點、方正一點都沒什麼太大的影響。這種原理的設計其實出現在相當多的地方，例如渦輪扇發動機的那個大風扇就是個涵道風扇(Figure 20)，此外在各位家裡都有的電腦風扇也同樣是涵道風扇的設計(Figure 24)。

Figure 20. 當代渦輪扇發動機的風扇也屬於涵道風扇 ^[18]

Figure 21. 實驗性質的 Bell X-22 正好體現了涵道螺旋槳圍殼的巨大體積 ^[19]

Figure 22. 氣墊船也經常使用涵道螺旋槳作為推進動力裝置 ^[19]

Figure 23. 有些直昇機的尾旋翼也是包裹在涵道裡的，其中一項好處便是氣流效率高 ^[20]

Figure 24. 電腦風扇可能是一般人家裡最常接觸到的涵道風扇裝置了 ^[21]

涵道螺旋槳效果這麼優秀，那為什麼在螺旋槳飛機上卻基本見不到呢？這就要說到缺點了！因為涵道設計的大問題就在於飛機的螺旋槳尺寸實在是太大，硬是要罩上一圈更大的「渦流阻斷器」的話，螺旋槳的效能是優秀了沒錯，但是相關裝置以及結構支撐器等等部件帶來的重量和阻力很可能最後得不償失！歷史上最為著名的嘗試可能就是 Stipa-Caproni 這架飛機了，整架飛機的設計為了這個涵道的效果可謂是煞費苦心，然而最後得到的卻是糟糕的飛行性能，因此後來就沒什麼人再去嘗試這樣的配置了！

Figure 25. 經常給人留下短胖呆萌印象的 Stipa-Caproni ^[22]

Figure 26. 將整個機身作為螺旋槳的風道的 Stipa-Caproni ^[22]

凍卵迷思

Thu, 10 Jul 2025 22:40:12 +0800

最近這些年來，凍卵這件事似乎越發流行起來，愈來愈多女性付諸行動進行凍卵。一時間似乎凍卵成了女性生育焦慮的萬靈丹，吃下這顆大力定心丸之後彷彿就可以高枕無憂。然而，現實的結果卻給我們啪啪打臉，那些凍卵後成功生育的比例竟然只是少數，而大部份卻是竹藍打水一場空。這當中究竟是哪兒出問題了呢？為什麼實際效果和理論預期之間竟有如此巨大差距？我認為這是因為我們對凍卵這件事存在一些想像與現實的落差，於是便對它抱有過份的期望，才導致這樣的結果。

眾所皆知的原因，女人在生育這件事上的時間相當有限，年紀大了以後就會愈來愈難懷孕，即便懷上了也是很容易遇上這樣那樣的疾病缺陷等等問題。總之以自然的情況來說，女人的最佳生育時間窗口短暫且一去不回，而當代的科學技術 – 凍卵 – 則相當幅度的保留並延展女性的生育機會。一下子，凍卵彷彿成為女人保命延壽(生育壽期)的靈丹妙藥，吃下一帖方子就好像給自己買了一個生育保險，好像就不用再焦慮於年年增長的年齡數字，有更多充裕的時間可以安心的拼搏事業或得遇良人。

然而從凍卵技術開始大量在民間應用至今，大約 20 多年的統計結果卻告訴我們，凍卵以後有回來使用這些卵的比例只有約 8%，考量取來使用的過程還存在的失敗率的話，那麼凍卵後成功生子的比例只有約 3%。從一開始的新科技引入使人們鉤勒起未來的美好想像，多年後回過頭來的這個數字表現，看見理論與實際的巨大落差，往往使人們虎驅一震。原來凍卵的功效並沒有想像中的那麼有用，並且凍卵顯然也並不能夠有效延長時限(以結果統計而論)，給予女性們所期望的從容。這之中到底發生了什麼事情呢？美好的理想為什麼不能成為現實的結果？女性們在面對這些新科技新技術的時候是不是陷入了什麼誤區，以致於對結果產生了錯誤的期待？

凍卵動機與失敗原因

一個女人為什麼會跑去凍卵，當然是因為遇到些事情而導致產生這樣的想法。這裡就來列舉一些常見的女性凍卵動機：

疾病因素

因為身體疾病的因素，比如卵巢早衰、癌症治療等，可能會導致女性快速喪失生育能力，因此想在此之前盡可能先行備份保留自己的生育能力。而這其實也是凍卵科技剛出來的時候所服務的主要目的。
因事業忙碌無暇顧及生育，而需要拖延生育時間。

這是現代許多事業女性間常見的共同困境與抉擇。人生的事業拼搏和發展升遷的黃金時期往往就在青年時期，絕佳機會往往一去不再有，卻偏偏女性作為一個碳基生物的生育黃金時期也重疊於此，並且可能更加短暫且同樣一去不返。有賴於科技的加持惠及之下，凍卵往往就成為現代女性作為拖延推遲生育時間的一個手段。
一時找不到合適的婚戀對象

佔凍卵人數最大宗的凍卵動機大概就是這條了：因為尚且找不到合適的婚戀男性。為避免失焦，本篇不探討所謂的合適到底是怎麼樣的，只談論現象既成的狀態。確實現代大量女性一時無法覓得足以認可的良人，也知道自己的生育時間不等人，在面對自身年齡焦慮和擇偶焦慮又不想要含糊找個人隨便嫁了的情況下，凍卵就成為給自己來個遊戲時間展延、緩解心理壓力，賺得額外一段從容擇偶時間的手段。
沒什麼想法，就當是買個保險。

最後有一部份人大概以渾渾噩噩來形容都不為過了。她們並沒有什麼積極的想法或規劃，也不是為了打拼事業發展，也不是焦慮於找不到對象，甚至於可能對找對象也還沒有什麼想法，抱持著真正隨緣隨意的心理狀態。可能她們也還沒想清楚這輩子到底想不想結婚？有沒有要生孩子？雖然對什麼都還沒有具體想法，但是確實眼看著自己的年齡逐漸增加，於是也跑去凍卵了。目的就是當作給自己買一個保險，以防「以後萬一想生孩子了呢？」

以上就是大部份凍卵女性常見的行動原因，可能還有一些比較少見的因素並未被提及，然而主要的大宗動機大約就是上面所列舉的這樣。雖然許多女性跑去凍卵，然而她們大部份並不能夠得到期望的好結果，這是從 20 年來的結果數據所展現的確定事實，凍卵之後成功生子的就只有 3%。那麼為什麼這些凍卵的女性最後大多失敗了呢？目前整理起來主要為以下原因：

事後自然懷孕

一個女性不論基於任何原因跑去凍卵，結果之後竟然(預期或非預期的)自然懷孕了，那麼通常很自然的就不需要回去使用當初所凍的卵了！這其實是一個很好的結果，可能也是所有其他結果裡面最好的。只不過因為所凍的卵最後並沒有被使用，因此像這樣的案例就會被歸在「未成功」的數據裡；可惜的是我目前並不能夠得知像這樣案例的佔比到底有多少？
人工生育本身具有失敗率

這項失敗因素使在所有因素裡面最預期自然的失敗因素了，那就是凍卵到受孕生產的整個過程並不是百分百保險的，其本來就具有各種風險和失敗率。這就是為什麼一般會建議凍卵要凍至少 20 顆的主要原因了！因為卵子本來就可能會取卵失敗、冷凍失敗、解凍失敗、受精失敗、培養失敗、植入失敗等等，因此需要以數量來填補風險，而一般來說冷凍 20 顆以上的卵子才能夠得到最終大約 90% 的成功率。 (至於能不能被取出 20 顆以上的卵則是另一個問題！)
身體機能老化而難以孕育

生育的極限並不只在於卵子而已！事實上以當前的技術水準來說，卵子的冷凍保存期甚至能比你的壽命還要長，然而在許多案例裡面卻是當女性想要啟用卵子的時候，面臨到她的子宮、肌肉、其它器官等已經老化到不能夠再承受懷孕的狀況。根本邏輯其實就是女性的懷孕生產極限本來就是由許多不同的身體狀態所決定的，並不只來自於卵子的限制；雖然卵子可能是首當其衝最早過期的項目，但卻不是唯一的一個！
年齡太大時才想到凍卵

許多人等到火燒眉毛的時候才知道焦急，才想到要行動，於是就造成了有部份的失敗案例其實是源自於太晚才想到要去凍卵的情況。年紀太大時才去做凍卵，除了前項所述的身體其它機能情況之外，擺在前面更大的問題可能是取不出足夠的卵！一來是卵子的品質本來就隨著年齡快速遞減，如果到了 40 歲才來凍卵，那自然本來就很難挑出品質好的；二來是在品質之外，體內的「庫藏」本來也就是隨著年齡而愈來愈捉襟見肘，愈難取出足夠數量的卵子。
找不到婚戀對象

許多凍卵最後失敗(再重申複習一次所謂的失敗是指未能最終使用並受孕)的案例是因為女人最終不能找到婚姻配偶而導致。雖然手上沒有具體的統計數字，但是依據部份處理人工生育相關工作的醫生的感受口述，這項原因是佔據相當份量的主要原因之一！因為找不到婚戀對象，自然沒有正確的精子可以和卵子配對受經乃至植入胚胎並受孕 (至於捐精什麼的則被歸類為下面一個原因的範疇)。
受法律限制而不能使用

還有些凍的卵不能夠被使用，是因為受限於我國法律規範的因素，而有一部份的人認為此項因素是我國與歐美諸國在凍卵使用率上面造成巨大差異的主要原因！我國法律在凍卵一事上的原則是以不孕治療為主，也就是說只有在女性具有合法配偶的情況下才能夠動用，至於單身無配偶但想要懷孕、想接受捐精、乃至同性戀伴侶想要懷育等等，都不在被允許使用自己所凍的卵的範圍，即使凍卵的女性死亡了也無法捐出所保存的卵子而必須要銷毀。 (這就是為什麼許多這類需求的人都要花費十倍以上價錢跑去國外那些沒有相關限制的國家做人工生殖的原因！)

迷思與陷阱

直接導致凍卵未能被成功使用的原因大約都列舉在前面了，然而為什麼會發生這些原因，並且集中大量發生導致失敗的結果呢？這當中就存在許多值得玩味思考和檢討改進的地方。以我的看法，我認為其中很大一部份原因是因為人們看待凍卵這件事的時候存在許多誤區，因為認知的偏誤而導致過高的期望或者錯誤的期待，從而使得最後沒能產生預期的結果。那麼這裡我就來分享我所察覺的這些陷阱或迷思。

不要等老了才去凍卵

許多人似乎對科技存在種不切實際的過度自信，然而事實上人類的科技是極其有限的，愈是在專家領域內的人往往愈加領略技術的極限，反而容易傾向保守。 (上面這現象在幾乎所有科技技術領域都是存在的，比如近年風行的人工智慧！)

凍卵不是萬靈丹，並不能夠解決所有的不孕問題；然而在面臨人工生殖本身的風險之前，許多女性在一開始就被困住了，因為連足夠數量的健康卵都難以收齊！如果一次取不出足夠數量且品質過關的卵子怎麼辦呢？那就只好多取幾次嘍！這就是為什麼較年輕些的女人可能只需要一次取卵手術就好，年齡偏大的卻往往需要取好幾次的原因了 (除了養卵取卵本身所造成的折騰外，每次取卵那可都是一次的手術費喔)。有時候女人面對此種情況，或許是荷包經不住多次失血，也會許是不願承受多次的身體折騰，因此取卵數偏低；而有的時候可能也不是女人不願意折騰，而是年齡實在已經大了，實在再榨也難榨出多少！那如果取卵數量少的話會怎麼樣呢？說實在的也是不會怎麼樣，這東西也沒有個標準的門檻限制說一定要取多少，只不過數量少的話，自然就是承受隨之提高的培養受孕失敗機率！

人類的科技水平遠還沒有達到能夠勝天的程度，而取卵凍卵本身也仍舊偏好依賴在年輕的時候去做這件事。然而問題是，如果我在你 25 歲的時候，還正在花樣年華、美麗動人，可能追求的豬哥還一大堆的時候，如果那時我叫你去凍卵，說「萬一你以後找不到對象……，萬一以後想生孩子生不出來……」那你猜猜我會不會被追著打到巷子尾？所以啊，人往往都是要到火燒屁股的時候才會開始著急，因此這問題實在也難解！

關於單身受孕和同性戀的議題

關於本國法律方面對於人工生殖的限制，我發現當下的新聞媒體和許多文章都喜歡把它導向到同性戀與單親的女性生育權議題上，然而如果站在實用主義的角度的話，其實探討這方面的意義反而不大！

就現形法規以不孕的治療為主要目的，因此女性凍卵後不能捐給別人使用，也不能在沒有配偶的情況下拿來使用，當然也就不能接受捐精的培育，也無法讓同性戀使用這項技術懷育自己的寶寶。關注這項議題的人多半將焦點放在生育權的話題，大意就是「我自己的卵我自己要用，為什麼不可以呢？」「雖然我沒有配偶，但我很想要生寶寶，用自己的卵，在自己的身上懷孕，為什麼不可以呢？」這些議題的目的就是要推動法規的鬆綁開放，讓許多原本需要去國外花上十倍以上價錢才能做的事可以在本國低成本的實行。這些議題是對是錯、是好是壞在這裡我不評斷，但是站在我一向主張的實用主義來看，其實根本對正常人影響不大，甚至於開放或限制都沒有太多基於實際上的意義。

對於無配偶想懷孕的情況，老實說其實可以直接去懷孕，根本不需要經過凍卵這個步驟！也許你說是因為一直找不到可以信賴托付終身的伴侶；問題是若要使用人工生殖懷孕，用誰的精子？捐精，誰捐的精？那個人難道就是值得托付終身的人嗎？你說捐精的話就無所謂，反正也不跟他過日子，只要基因好就好了；那麼其實這樣的話你也可以直接找個基因好的人(也就是長的帥，頂多再加上聰明)懷孕就好了！反正子宮長在自己身上，女生自己想要懷孕還不容易嗎？反正也只需要對方出個精子，至於他人怎麼樣根本也無所謂是吧，就和捐精是一樣的。這樣選擇面一下子就打開了，反正也不和男生過日子，根本無需要糾結過多不必要的擇偶條件；並且站在男生的立場也同樣如此，可以玩玩享受又不用負責任也不會被糾纏，也太容易願意配合了！在這樣的情況下，會發現「因為一直遇不到合適的對象所以拖到大齡」這個顧慮就直接消失了，「看得上我的人，我看不上他；我看上的人，他看不上我」帶來的難題也能立刻打消九成 (因為站在男性的視角，上述的問題通常只有在考慮長期關係的時候才會存在， 至於沒有壓力、不用負責的極短期或一夜關係則通常不會困擾阻礙男性)。其實這就是所謂的「去父留子」，或者用更加貼近民間語氣的話來說就叫作「自願當單親媽媽」。多少女孩子千百萬個不願意卻做了單親媽媽，哭天哭地的，而你卻主動希望做單親媽媽。你不在意通常單親媽媽會遇到的那些問題，並且自己也有能力能夠承擔獨自生育養育的各種支出和付出，那還有什麼需要糾結的？

因此如果你真的想要生小孩，真的不在意也無所謂有沒有人生的配偶、伴侶，那麼其實立刻就可以行動了，根本不需要走凍卵、捐精，然後拖到高齡產婦年紀再去做人工生育這一條路。這就是為什麼我說站在現實的實用立場上，法規在凍卵這件事上的限制，對於想要單親生育的女性來說無關痛癢的原因了！

對於同性戀的部份，確實除非經過人工生育否則不能夠產生自己的孩子，然而放寬凍卵相關法規限制其實實際意義並不大！兩個女人能產生受精卵嗎？(至於兩個男的就完全不用討論了，根本不可能！) 我其實不知道以當前的科技水平而言能不能夠做到把兩個卵子的 DNA 提取後合併成一個受精卵？但無論能還是不能，其實這已經遠遠超出「凍卵」這件事所涵蓋的範圍了，單純放寬凍卵的限制並沒有辦法解決同性戀所需要的生育問題，也許更該先討論的可能是基因轉化、人工製精、合成胚胎等等議題 (我用的名詞應該不正確，因為我也不是生物科技研究員，搞不好有些正確的名詞也根本還沒誕生， 所以請自己望字生義)。所以在此情況下放寬凍卵限制對於同性生殖沒有任何意義與幫助！

也許有人會問說「那可以用捐精的精子啊！」好的，那麼用誰的精呢？不管用誰的，肯定不會是伴侶的吧？如果都打算生的孩子不是伴侶的種了，那麼根誰懷孕不是懷孕呢？甚至兩個人一起都懷孕又何嘗不可呢？於是又回到了前面單身女性自願懷孕生育的一樣情況，完全無需要繞一圈走凍卵再人工生殖這條路！

因此從現實的層面來說，凍卵的相關法律限制對於不論是無配偶無伴侶的單身女性生育，或是同性戀的生育問題，其實都不構成什麼真實的問題。而那些對於這方面的討論話題，特別是將焦點導向到生育權與同性戀的行為，其更多的可能是以爭取政治上的話題與利益為目的。

凍卵並不能夠提升女性魅力

再回顧一下思考為什麼要去凍卵？其中一項可能位列第一名的動機，甚至有可能是佔大頭的主要動機，便是「一時找不到合適的對象」，而凍卵的期望作用便是給自己延長找對象的時間。然而這裡我卻告訴你用凍卵來解決找對象的問題是大概率要徒勞無功的！

這要牽涉到求偶與匹配的邏輯了。如果說求偶尋覓就像是在一個房間裡尋找遊戲活動主持人所埋藏的彩蛋的話，那麼延長遊戲的時間確實可以幫助許多來不及找到彩蛋的人尋寶過關；然而若房間內其實根本沒有彩蛋呢？如果彩蛋的數量只有遊戲人數的一半，而已經有一半的玩家拿到蛋出場了呢？在這種問題本身無解的情況下，就算尋寶時間再延長多久都是沒有用處的！而這其實就是這些因為找不到對象而去凍卵的人所面臨的真正問題，也是為什麼凍卵對於解決這問題毫無幫助的真正原因！

說到大齡剩女為什麼剩下來的萬年經典狀態，無非就是「看上我的，我看不上他；我看上的，他看不上我！」那麼這裡我們就先跳過女生看不上的那一部份不管，反正應該沒有哪個女生凍卵的原因是想要看看「多花點時間也許能讓自己接受那些原本看不上的男人」吧？別鬧了！女生凍卵的目的當然是想要用時間來獲得那看得上的男人的可能性。那麼就要接觸到核心的問題了，
問題一：為什麼那些你看上的男人們看不上你呢？
問題二：凍卵對於解決問題一有什麼正面意義？
其實對於稍有點智慧的人來說，答案到這裡已經呼之欲出了。

很多女人認為……，其實正確應該說是去凍卵的裡面大多認為沒找到對象是因為緣份還沒到，認為若有多一點時間就可以捕捉到那個想要的人，可能壓根沒有意識到面臨的其實是一個結構性的困局而不是單純遇的人不夠多，即便可能在她的求愛經驗中早已發生了太多次「我愛的不愛我，愛我的我不愛」這樣的事情，即便事實的真像歷歷在眼前都沒有讓她意識到這絕不是單純機率的問題！不論是真沒有意識過還是內心不願意承認，既然這裡講現實求務實，那就不能夠不去揭開並直面這個問題。那些沒看上你的男人，他們之所以沒看上你的原因可能有多種，比如你年齡大、身材不好、長相不在人審美上、個性蠻橫嬌作、腦袋空空、負債累累、……等等等等。這些原因可能多種多樣，然而共同不變的一點是：凍卵對解決這些問題一點幫助都沒有！凍卵所能做的只是延長你的生育能力，而不能夠增加你的吸引魅力！嫌棄你年齡大的男人不會因為你去凍卵後就不嫌了，嫌你身材長相不達標的也不會因為凍卵而降低標準，其他如性格、文化、能力等等亦是同樣如此。因此為了這些目的的凍卵行為，到頭來除了花費大錢給自己買一個幾乎注定會破滅的希望之外，沒有什麼用處。當然你可以反駁也可以否認，不過現實的統計數據已經明白的告訴我們那些走在你前面的人親身淌出來的結果了！

其實我聽聞過一些在人工生殖領域執業多年的醫師，在某些環境氣氛到位的情況下，語重心長的對前來的女性說：「與其花錢跑來凍卵，倒不如把錢省下來，趕緊去找個對象，比較實際！」上面那是醫生的建議，而若是讓我給建議，那我會說：如果真的想要孩子，如果真的擔心再過幾年可能會生不出來，那就趕快去生孩子吧！現在這個社會早就已經不會把父不詳的媽媽拿去浸豬籠了，對單親生育的接受眼光也相當寬容與理解，你完全可以去生一個自己的孩子，不需要非得抓一個男性來綁住不可。至於這時候可能有少部份腦袋不知道裝什麼的女性會跳出來說：「女人的價值只在生育嗎？」「女人非得要生孩子嗎？」那我只能說你說的沒錯也完全正確，並且事實上如果沒打算生孩子的話，凍不凍卵其實與你一點關係都沒有，其實你根本不需要去煩惱凍卵的事情；那幹嘛還焦急跳腳呢？

有關凍卵補助

這幾年政府為了低迷的生育率而不斷推出一系列措施，其中一項就是補助女性進行凍卵。同樣的，對與錯、應與不應，由各位自己去做評斷，而我只在務實的層面去批判這件事，那就是補助凍卵等於拿錢丟到水裡去，毫無效益！為什麼凍卵沒有效益？相信如果是本篇從頭讀下來的讀者肯定不會有這樣的疑問。凍卵所費不貲，大量補助凍卵那更是耗資巨大，然而依據已有的統計資料來看，能夠促成的新生兒卻少得可憐！因此我相當反對花大錢去做補助凍卵這樣的政策，成本高昂且效益過低。

那要如何有效解決生育率過於低落的問題呢？因為本次主題不在這，所以不會過多論述，只簡單提一些非常簡單原則的概念。站在工程的角度，要解決一個問題首先你得挖掘出造成問題的根本原因，或至少是大部份的主要因素，然後才能夠對症下藥。那麼生育率低下難道是因為大家喜歡年齡大生孩子嗎？還是因為被迫不得不年齡大了才生孩子？或者是根本不願意生孩子？對於被迫不得以的，你得找出什麼原因導致女人被迫不得以；對於不願意的，你得找出她不願意的原因，然後才是思考解決方案的步驟。既然許多生育的困難是來自於晚生，那麼只要能夠讓女人願意早點生孩子，即便平均只提前了幾個年，我想這成本效益都遠高於花大錢去補助成效低劣的凍卵！

參考資料

螺旋槳 3：各種奇妙問題

Sun, 06 Jul 2025 00:44:32 +0800

這次要來談論關於螺旋槳的運作特性，包含許多可能在直覺之外的奇特現象。或許有些人會說「什麼？螺旋槳不就是大號電風扇，開強一點風就大一點，開弱點風就小點這樣嗎？我以為可以調整槳距已經足夠複雜了，怎麼都這樣了還沒完啊？！」是的，螺旋槳推力系統在實際應用中的複雜度並不僅止於直覺所理解的部份，本篇就讓我們來看看它還有什麼奇幻的特性吧！

螺旋槳的通常旋轉方向

為了避免需要重複解釋同樣的邏輯，因此在探討螺旋槳產生的各種奇妙反應之前，得先來解釋關於螺旋槳旋轉方向的問題。

「螺旋槳是向著哪個方向旋轉的呢？」

這個問題的標準正確答案是：「不知道，看你想讓它怎麼轉都可以！不過話雖如此，然而在特定的應用上確實存在一般的慣例。」以飛機螺旋槳來說，大部份的螺旋槳是右旋的。也就是說以一般常見螺旋槳安在飛機頭的情況來說，當你坐在駕駛座位上向前方看的時候，那麼就會看到螺旋槳是順時鐘旋轉的。如果螺旋槳是安在飛機後面的話，那麼從座位扭頭向後看，會看到螺旋槳也同樣是順時鐘旋轉；不過若站在同樣的飛機外面，從飛機尾巴後面觀看的話，那麼會看到螺旋槳是逆時鐘旋轉的。

那麼在以下各種情況的探討中，便會預設使用一個同樣右旋的螺旋槳。當然實際上也可以安裝個左旋的螺旋槳，那麼所描述的各種現象就會對稱反向過來；不過除非有特別描述交代，否則以下探討都將假設在使用了右旋螺旋槳的情況下。

反力矩

Figure 1. 螺旋槳反力矩示意圖 ^[1]

牛頓告訴我們力與反力是同時成對存在的。那麼當我們用發動機對螺旋槳施加力矩使其旋轉的時候，自然就會有一股大小相等、方向相反的力矩施加在我們的飛機身上，如同上圖(Figure 1)所示意的 Reaction，給飛機施加一個向左滾轉的力矩。這個力矩有多大呢？力與反力大小相同，也就是說發動機此刻正好輸出多少扭矩，那麼反扭矩就是多少；換句話說基本就是油門推推愈大則反力矩同等愈大。這就是為什麼單引擎小飛機在低速準備進場降落的時候，如果遇到什麼狀況想要放棄降落重飛的話，那麼油門一推，飛機就容易左翻(因為大部份螺旋槳是右旋的)的原因！

槳尾噴流

Figure 2. 螺旋槳加速後的氣流柱會收窄，而前面則會吸入範圍更大的氣流

螺旋槳的作用就是用來把空氣加速向後推出去，因此空氣在經過螺旋槳盤面之後會被加速，在螺旋槳後面形成一股高速氣流，如上圖(Figure 2)所示。並且注意到，螺旋槳前面受影響而被吸入槳盤的氣流範圍(也就是隱形的虛擬流管管壁直徑)是比較大的，而從後方噴出的高速氣流則其範圍會縮窄，這個現象會對飛機的性能特性產生相當大的影響。

這個現象是由於流體的連續性而造成的。氣流被加速往後吹跑了，那總有人(其它周圍的空氣)要進來補充空間吧，否則不就變真空了？既然螺旋槳前面的氣流流速比後面慢，自然只能夠擴大吸拉空氣的面積範圍，才能夠維持盤面進出的空氣流量相等啦！況且螺旋槳並不改變前後氣流的壓力、密度，至少理論上也不會改變氣流的溫度，因此唯一只能讓前方吸入更大範圍的空氣才能夠維持前面進入的空氣量和後面出去的空氣量相等，而這就是開頭所謂的「流體(質量)連續性」。這就是為什麼螺旋槳前面吸氣的範圍會擴大的原因，並且其實相同的原理也同樣是螺旋槳後面氣流寬度會收窄的原因。

另外，以上所描述的原理與現象並不只出現在螺旋槳上面，只要任何前面吸氣後面噴氣的動力裝置其實都會產生同樣的現象。

那麼離開螺旋槳的這股高速氣流會給飛機帶來什麼影響呢？考量到一般常見的配置都是將螺旋槳放在前方的情況，那麼這股高速氣流就會吹襲在後面的飛機機身、以及機翼、尾翼等各部位，造成一股把飛機給向後推拉的阻力，降低飛行速度，也同樣降低飛行效率。

槳尾氣旋

Figure 3. 通過螺旋槳的氣流不只是加速，還會被帶動旋轉起來！ ^[1]

空氣在經過螺旋槳盤面之後不只會被向後加速，也同時會被螺旋槳給攪動旋轉起來，因此在螺旋槳後面的噴流並不是簡單的直線向後吹的高速氣流，而其實是被扭轉旋轉的螺旋氣流。

為什麼空氣經過螺旋槳後會旋轉起來呢？這是因為螺旋槳槳葉產生的氣流阻力，在槳葉運動的時候拖拽拉扯空氣，而使空氣被拖動而旋轉起來的。回顧我曾解釋過的機翼升力原理 ^[2] ，即便是考慮一個外星人製造的機翼，不存在任何摩擦阻力，完全不消耗氣流動能，而僅僅只是改變氣流方向而已，它也會產生阻力。這個阻力的來源是來自於機翼將下圖(Figure 4)所示的水平方向速度分量給減速了，並且這張圖展示的是如前所述的完美無摩擦狀態，而實際上因為摩擦等其它阻力項的存在，水平速度會減少更多！那麼將所示的這個同樣原理放回螺旋槳槳葉上，可不就是當槳葉在移動(轉動)的時候，會導致拖拉空氣跟著它移動的方向一起動起來、旋轉起來的原理了！

Figure 4. 水平方向的氣流被翼面折轉方向後，其水平之分量減少了，這就是螺旋槳氣旋產生的根本源頭

螺旋槳所產生的這個旋轉氣流會對飛機產生什麼樣的影響呢？首先這氣旋吹在機身上肯定會造成一個令飛機右滾轉的力矩，不過因為驅動螺旋槳旋轉本身就會產生左滾的反力矩，因此氣旋所造成的這個右滾力矩可以被部份對消，影響反而不大。第二個影響則是這個氣旋吹打在機尾的垂直尾舵上，會導致產生一個使飛機向左偏航的力矩，如同上圖(Figure 3)所示，而這才是氣旋給飛機操縱帶來的真正較大影響。

槳尾氣旋除了會吹在舵面上造成偏轉飛機的力之外，還會導致螺旋槳的效率降低，以及使得飛機阻力增加！對於螺旋槳效率的部份，簡單的理解就是螺旋槳將發動機給予的能量施加在空氣上，使空氣向後加速而得到反作用力，然而有空氣實際上卻不是直直被往後加速的，而是有一個分量跑到別的方向去了(使氣流發生旋轉)。空氣在其它方向的加速對於推進沒有作用，然而它卻確實需要吃掉螺旋槳提供的能量，成為一種無用的消耗，使得效率降低。

對於造成阻力的方面，考量一般最常見的螺旋槳放機頭的情況。氣流吹在飛機身上本就會產生阻力，螺旋槳吹出來的氣流速度肯定比飛機本身飛行速度所帶來的相對風速更快得多，因此阻力又更大了。等於螺旋槳前面好不容易吹出來用以推進飛機的高速氣流，立馬後面就被飛機的本體給吃下來，成為拖後腿的阻力。這部份在前面的螺旋槳噴流影響那邊已經解釋過，然而雪上加霜的是這個氣流還不是直直吹的，而是帶旋轉的！這種帶角度吹向機翼和尾翼所產生的阻力又要比直直吹過去所產生阻力更大了！因此槳尾氣旋不只會降低螺旋槳本身的效率，還會因為氣旋的效果而增加飛機的阻力。

槳尖渦旋

Figure 5. 機翼尖端切過煙霧使得能夠看見尖端所產生的渦旋 ^[3]

機翼透過在上下兩面製造壓力差而產生升力，這點以前解釋過 ^[2] ^[4] 。在二維機翼剖面的分析中我們知道上下翼面的氣壓差被機翼給阻隔了。然而現實世界的機翼是處在三維空間的，機翼總是有個盡頭結束的地方，也就是兩邊的尖端，那麼機翼下面的高壓就會翻越機翼尖端的邊緣而充填入上翼面的空間，這就產生了如上圖(Figure 5)所示的翼尖渦旋。既然說螺旋槳槳葉就和機翼是一樣的，那麼機翼翼尖渦旋的這個現象也同樣會出現在螺旋槳上面，也就是本節所述的槳尖渦旋。

Figure 6. 螺旋槳誘導渦流示意圖 ^[5]

這個渦旋的存在會導致什麼樣的影響呢？會導致螺旋槳的功效降低！用比較白話直覺的方式來說，槳葉下翼面的高壓被洩到上翼面去，會導致上下壓力差減小，自然導致產生的推力會縮減。從另一個方向來理解，在前兩篇 ^[6] ^[7] 中，我們已經知道螺旋槳槳葉上的氣流主要受到螺旋槳旋轉轉速、和飛機前進的空速的共同影響。而用比較學理的話來說，就是槳尖所形成的這個氣旋會在槳葉上產生一個與飛機空速相同方向的氣流，也就是說它把槳葉所感受到的空速氣流給放大了，如上圖(Figure 6)所示。這會導致什麼結果？導致槳葉上的氣流攻角變小！比方假設現在槳角擺了 45 度，理論上氣流攻角好像是 45 度，但是因為飛機本身在移動的關係，所以還要疊加上氣流速度的影響，使得實際的氣流攻角只有比方說 30 度；然而還有一個槳葉葉尖製造的渦流影響還沒被考慮，若將渦流所誘導造成的這個流速給加進來的話，那麼實際的槳葉攻角可能就變成比方只有 15 度。最後結果就是升力(推力)變更小了，阻力(扭矩)卻變更大了！

這個額外的氣流是由於槳尖製造的渦流所誘導產生的，因此就被稱為「誘導氣流」，就是我在之前文章曾經稍微提及 ^[6] 卻沒有解釋的那個誘導氣流。而因為誘導氣流所造成的額外阻力，就被我們稱為「誘導阻力」。另外，這個誘導氣流的來源並不只來自於某支槳葉它自己，而是所有的槳葉都會製造槳尖渦流，也同樣所有槳葉都會受到全部渦流的綜合影響。因此螺旋槳的槳葉數量愈多時，其實效率會愈低！

側滑效應

Figure 7. 當螺旋槳盤面並不是正對著氣流的時候，吹到螺旋槳上的氣流(藍色)可以分解成兩個部份(青色) ^[8]

通常我們在介紹螺旋槳或思考螺旋槳相關效能什麼的時候，往往都有意無意的忽略側滑氣流，然而實際上側滑氣流確實經常會存在，也確實會給飛機的操縱性造成一定程度的影響！比方在發生如上圖(Figure 7)的飛行動作的時候，飛行速度所產生的氣流就不是垂直吹在螺旋槳盤面上的，而是帶有一個夾角。這樣的話，我們可以將氣流分解為兩個分量，一部份仍然是垂直於槳盤的氣流，另一部份則是完全平行於槳盤的氣流(如上圖的青色短箭頭)。對於那垂直盤面的氣流會產生什麼作用，我們已經介紹過很多，相信已經非常熟悉了，就不多贅述；而那平行於盤面的氣流就是本節重點所在：側滑氣流。

Figure 8. 螺旋槳槳葉所感受到的氣流，來自於槳葉自己的移動速度(橙色)、以及側滑氣流(藍色)相互加減的結果 ^[1]

側滑的氣流會使得槳葉受到不平均的氣流加減速效果。以上圖(Figure 8)來作為說明示例，螺旋槳槳盤上有一股側滑氣流從圖片的上方往下吹來，那麼當槳葉轉動到右側位置的時候，槳葉的運動方向面向直吹而來的側向氣流，使得槳葉所受到的實際風速更大，因此槳葉在這裡會得到更大的升力；相反的，當槳葉轉動到左側位置的時候，槳葉的移動方向與從槳葉背面吹來的側滑氣流同向，使得槳葉受到的實際風速降低，因此槳葉在這個位置的時候升力減小。

如此我們就知道，當側滑氣流作用在螺旋槳盤面上的時候，會造成槳葉在不同位置上產生的升力不平均的結果。以上圖(Figure 7)飛機正在以向右偏航的姿態側滑的情況來說，螺旋槳盤面上就會出現一股從左到右的側滑氣流。考量到螺旋槳旋轉方向一般為右旋的情況，因此飛機的螺旋槳盤面在下方的部份就會產生比較大的推力，而盤面上方的推力則降低，綜合的結果就是帶來一股使飛機仰頭的力矩。以此類推，當拉桿使飛機抬頭以正攻角的姿態飛行時，螺旋槳盤面上的側滑氣流就會產生一股使飛機向左偏航的力矩。這就是為什麼在玩一些比較擬真的飛行遊戲時，當我們擺動操縱杆試著讓飛機往我們想要的方向改變姿態的時候，飛機卻總是會在直覺預期之外的方向也產生反應的原因，之一。不過好在對於螺旋槳飛機來說，一般通常這樣的側滑偏角都不大，一般情況可能約就幾度左右的範圍，所以影響確實是存在但份量有限；然而在有些應用上，比方說直昇機，那麼側滑現象就是相當稀鬆平常並且佔據份量了！

陀螺效應

Figure 9. 陀螺效應示意圖 ^[1]

螺旋槳作為一個高速旋轉的質量塊，自然會產生陀螺效應。陀螺效應實際上為兩種特性：定軸性(inertia)和逆動性(precession)。其中的定軸性就是陀螺轉軸會傾向於維持方向而抗拒改變的特性，也就是說如果要施力改變轉動軸的指向的話，會感受到比陀螺不旋轉的時候更大的轉動慣量。定軸性造成的影響是在我們想要改變螺旋槳轉軸的朝向時，也就是俯仰與偏航操作時，會受到較大的慣性阻力。不過因為螺旋槳質量佔比整個飛機很小，並且產生的影響也是各方向均勻一致的，因此通常影響微小，一般也會直接忽略掉這一部份。

飛機螺旋槳真正比較有感的陀螺效應是其中的逆動性部份，就是當我們施加一個力矩在陀螺身上的時候，會在順著陀螺旋轉方向偏移 90 度的位置產生反應力矩，使得陀螺受力而偏轉(或傾倒)的方向和我們施力的方向不一樣，如上圖(Figure 9)所示。在實際的飛機上，高速旋轉的螺旋槳本身就是個大陀螺，因此當我們操作俯仰或偏航時，都會因為陀螺的逆動性而產生額外的動作反應。例如在下圖(Figure 10)的示例中，當操作尾舵使飛機低頭的時候，就會因為螺旋槳的陀螺效應而產生一個使飛機向左偏航的力道。

Figure 10. 當操作飛機向左偏轉時，因為螺旋槳的陀螺效應而產生一股使飛機低頭的力矩 ^[1]

不知有沒有人注意到？欸這陀螺效應產生的力矩，和螺旋槳側滑效應產生的力矩好相相反啊，那它倆不就互相能消抵了嗎？答案是不能！且先不說兩者產生的不平衡力可能並不相等，它們產生的時機也是不一樣的。陀螺效應在有加速度的時候產生，也就是說只在正在操作飛機改變姿態的當下產生，而側滑效應只和側滑角度有關係。意思就是說比方當我拉動操縱桿讓飛機抬頭的時候，除了當然會有主要的抬頭的力道之外，也會感受到一股使飛機向右偏航的力道，這是由於陀螺效應所產生；然而當飛機往上抬頭的這個動作做完，現在一直維持固定抬頭攻角飛行的時候，陀螺效應就沒有了，這時會感受到的主要偏航力量可能來自於側滑效應，會施加給飛機向左偏航的力道。因此這兩者雖然給飛機造成的擾動方向相反，但並不能夠彼此對消，而是會在不同的時間點跳出來！

總結

如此這般，螺旋槳的這些特性給飛機帶來的影響主要分為兩個部份：使推進效率降低、以及使操控反應複雜化。其中關於效能和效率的部份，主要是工程師們要去解決的問題，並且這些問題的存在並不會產生「不對稱」、「不協調」的不良影響，因此對於實際操作的飛行員視角來看反而不是什麼需要在意的重要事情。對於第一線操作飛機的飛行員來說，更加重要的是螺旋槳的這些這樣那樣的特性給飛行操縱所帶來的複雜性和迷惑性，特別是在未經熟練的飛行員操縱下經常會產生許多並不符合直覺的複雜反應，若搭配「合適」的飛行條件狀況的話甚至容易發生事故。

比方說在螺旋槳飛機大行其道的二次世界大戰時期，小機身配上單發大馬力的戰鬥機的這些螺旋槳效應就特別明顯。如果再加上低速起降時飛機不易控制，還特別需要油門時大時小推來推去的操作條件，再加上起降環境本身又窄小嚴苛的情況下，比方說航空母艦上的起降，就特別容易發生事故！也因為大部份螺旋槳都是右旋的關係，當在航空母艦降落時若突然出個什麼事要重飛還什麼的，油門一推大，飛機就容易往左偏或往左翻。這就是為什麼航空母艦的艦島大多喜歡蓋在右側而非左側的主要原因了，因為在左側容易被降落失敗的飛機突襲！此外螺旋槳的陀螺效應也是為什麼一戰時期的旋轉發動機 ^[9] 曇花一現後很快就被放棄掉的原因，之一。因為發動機本身就是質量相當大的東西，再整個旋轉起來導致飛機的陀螺效應相當嚴重，起降時相當容易出事故，特別容易害死菜鳥飛行員！ (不過其實當時的時代下整個航空都還在萌芽探索時期，導致飛行員意外的因素是遠不只單單這麼一項就是了！)

1. Propeller aerodynamics

2. 翼型系列 1：機翼升力原理

3. Wingtip vortices caused by high pressure

4. 翼型系列 3：那些升力原理哪裡錯了？

5. Bladed Propeller

6. 螺旋槳 1：原理簡介

7. 螺旋槳 2：變距螺旋槳

8. Grumman F6F Hellcat

9. 活塞引擎 2：多缸佈局

螺旋槳 2：變距螺旋槳

Sun, 15 Jun 2025 19:55:32 +0800

這次來探討一個在螺旋槳上面佔據相當重要性的主題：螺旋槳的變距。

Figure 1. 可變螺距螺旋 ^[1]

在前篇 ^[2] 提到螺旋槳葉片所感受到的氣流角度是變化的。一片槳葉的每個位置因為與旋轉軸心的距離不同而導致移動速度不同，然而這點其實相當容易解決，只要把槳葉設計成我們看到的那個扭轉造型就可以了。真正比較複雜棘手的部份來自於因為螺旋槳的轉速變化、以及飛機飛行速度不同而導致的槳盤迎風氣流速度不同，這兩項都在變動的氣流流速導致葉片上所感受到的氣流角度時常變化且不易捉摸。當然我們可以不理會這些問題的存在，並且直到現代也有相當龐大的應用領域就是這麼做的，如輕航機、遙控模型飛機、和各位家裡的電風扇等等。只不過這樣的缺點也很明顯，當飛行速度愈來愈快的時候，螺旋槳的效率就會愈差，愈難以再繼續有效提供推動力，導致難以再繼續提高速度。為此，人們發明了可以改變槳葉螺距的變距螺旋槳，如上圖(Figure 1)所示。

槳葉角變動範圍

Figure 2. 螺旋槳槳角區間

可變螺距的螺旋槳可以改變槳葉的角度，一般來說槳葉可設置的角度粗略分為三個區間：正槳、反槳、和順槳，即在上面的示意圖(Figure 2)中分別標示為淺綠、淺黃、和淺藍的範圍。當然，實際飛機上的螺旋槳可能因為各種設計需求的緣故，其實際能夠使用的區間也許會比上面所示的更少更窄。

先看反槳的情況(如圖 Figure 2 紫色槳葉)，此時的槳角很低甚至是負的，使氣流作用在槳葉上產生的推力不再推動飛機向前，而是將飛機反方向向後拉。這個作用就像是汽車上的倒退檔，使飛機產生一個向後退的力，在地面機坪上操作飛機向後滑動的時候有用處；特別是在那種左右都有螺旋槳的飛機上，還能夠做到能讓飛機原地掉頭轉向的動作，用處很大。當然，在正常飛行的狀態下使用這個檔位就會給飛機和整個動力系統帶來相當大的負擔，因此許多飛機的操作設計只允許在地面上使用這個檔位。

順槳(如圖 Figure 2 藍色槳)則是將槳角直接拉到擺平(約 90 度)，與飛機前進的氣流同向。這個槳角基本只有一個用途，就是當飛機飛在空中且發動機故障或燃油耗盡而停止運轉的時候。此時螺旋槳已經完全沒有產生推動動力的作用，而只剩下阻力板的作用，因此在此情況下將螺旋槳調整至順槳的位置，可以使螺旋槳產生的氣流阻力減少至最低。

Figure 3. 畫面右邊的螺旋槳正好處於順槳狀態 ^[3]

再來看看在一般平常狀態下最常見的正槳範圍。槳角可以使用的範圍那麼大，那麼應該在什麼情況下使用怎麼樣的槳角呢？在下圖(Figure 4)中便示例了三種不同的狀態。其核心原理就是使槳葉與相對氣流之間維持在最佳攻角上，攻角過大會產生槳葉失速問題，攻角過小則螺旋槳不能有效產生推力，還可能因為轉矩過小而導致發動機超速運轉！那麼既然槳葉的相對氣流是由飛機的前進速度也就是航速、加上槳葉自身運動速度也就是螺旋槳轉速所共同影響的，自然槳角的選擇就會和這兩個速度之間的關係有關。

Figure 4. 不同空速和槳葉速度搭配下的槳角

上圖(Figure 4)的橙色槳和藍色槳分別對應相同螺旋槳轉速下處於不同航速的狀況，當航速高的時候槳角就需要大一點，而航速低的時候槳角則要小一點。那麼當我想要加點油門給飛機提速的時候呢？上圖橙色槳和紫色槳正好表達了這種情況。在航速沒變的情況下，我給發動機加力，自然螺旋槳就轉的比較快了，因此這時的槳角便需要調整至比較小的位置；相反的當欲降低發動機出力而使螺旋槳轉速變慢的時候，槳角便需要往大的方向調整。總結而言，最佳槳角主要和飛機航速、及螺旋槳轉速二者有關，當航速高而轉速低時需要大槳角，而當航速低而轉速高時需要小槳角；至於航速與轉速二者皆高、或者皆低時，則最佳槳角無法簡單的判斷，需要更仔細的計算二者之比例後才能夠決定。

這些調整看似凌亂，槳角、空速、轉速等等彼此都有關係，互相影響，但其實更加簡單直白的原理，就是在任何狀態下，使槳葉與氣流維持一個不變的攻角！ 回顧上圖示意的幾個不同狀態，雖然空速、轉速、和槳角都變來變去，然而槳葉與氣流的攻角卻都是一樣的，而槳葉角度的手動變更行為其實也是為了使攻角保持一致。更進一步探討，其實攻角也不一定非要在一個固定的數值上維持不動，而是在一個範圍內都可以使用，只要攻角不至過大而發生槳葉失速，也不會過小而讓發動機因為負載過低而超速運轉，就都是可以使用的攻角區間。

上面說到無論狀態如何變化，槳葉的攻角會由人為控制使其大致維持在固定的數值上，但在此大條件之下其實攻角還是存在一個可以變化的浮動範圍。如果攻角偏高，甚至處在接近槳葉失速的邊緣，則此時雖然看似槳葉的升力大，但阻力同樣也大，因此轉軸扭矩大，發動機負載高，轉速自然會偏低；總和起來推力反而偏低，但發動機輸出功率同樣偏低，總體動力系統的運作效率比較高 (類似原理解釋可參閱往期內容 ^[4])，更白話來說就是省油。相對的如果讓槳葉攻角偏低，此時看似槳葉的升力係數也偏低，但是因為扭矩小，發動機負載低，自然轉速會升高，反而能夠產生更多的升力(推力)；也就是說雖然效率降低也更耗油了，但是卻更能夠壓榨發動機的馬力輸出 (亦可參閱往期內容 ^[5])！

總結對於槳角的調整目標，首要任務是確保在任何空速和轉速之下，讓葉片氣流攻角都處在可以正常工作的範圍，不會讓槳葉發生失速，也不會使發動機超速運轉。在確保槳葉處在上述的可工作範圍區間下，次要任務則是依據當下對動力的需求調整使攻角偏高或偏低。攻角偏高則動力系統效率高，適合巡航等狀態使用；攻角偏低則系統效率差但可爆發更多動力輸出，適合需要短時間加速的場合使用。也許至此許多汽車駕駛已經發現了，螺旋槳槳角也就是槳距的調整，其地位即類似於汽車上的排檔變速機構。低速時使用低速檔(小槳距)，高速時使用高速檔(大槳距)；需要臨時加大動力提速時需要降檔(偏低調整槳距)，要省油巡航時則使用高速檔(偏高調整槳距)。

恆速螺旋槳

理論上來說，能夠動手改變螺旋槳的槳角(或稱槳距、螺距)，就已經足夠應付各種不同發動機轉速和飛行速度下的各種狀況了，只是這樣的操作需求在實際的飛行中卻給飛行員帶來不小的操作負擔。因為飛行員必須要隨時關注空速(也就是飛行速度)和發動機轉速，並且立刻做出對槳距的調整行為。然而空速和轉速是時刻都在變化的，因此槳距的調整也同樣需要一刻不能停的調整；並且調整槳距的行為本身也同樣會導致轉速發生變化，因此調整槳距的整個行為其實頗有複雜度。如果說飛行員沒有別的事情幹而只需要做槳距調整這件事的話，那倒也不是什麼大事，但是偏偏飛在天上要操作的東西、和要注意的東西還有很多別的，那麼調整槳距的這件事情就會導致飛行員相當大的壓力。但是在上一節的內容已經說明過了，這些變來變去的調整最終其實就是要讓槳葉攻角維持不變罷了。那麼如果能夠發明一個什麼機構能夠依據氣流狀況自動改變槳葉角度，是不是就可以在槳距這件事情上減輕飛行員的操作負擔呢？是的，事情的確是這樣，並且也確實存在一個作用與這個目的相當接近的設計，這就是：恆速螺旋槳。

Figure 5. 恆速螺旋槳結構 ^[3]

恆速螺旋槳顧名思義，就是能自動保持螺旋槳維持在一個固定轉速的裝置。螺旋槳在旋轉的時候會驅動圖中(Figure 5)標示為 Governor Drive 的齒輪，驅動著上方標示為 Governor 的離心飛錘。飛錘轉速高於需求的時候便會因為離心力而向外張開，反之在轉速不夠的時候就會因彈簧的力道而向內收縮。螺旋槳的液壓機構(或可能有些設計比較喜歡使用齒輪而非液壓，但原理是一樣的)便能依飛錘的狀態去調整螺旋槳槳距。當偵測到螺旋槳轉速高於所設定的目標轉速時，便會自動增加槳距以降低轉速；相反當偵測到螺旋槳轉速低於目標轉速時，便會自動減少槳距以增加轉速，最終使螺旋槳趨向於維持在所設定的轉速上固定不變。

恆速螺旋槳大約是在兩次世界大戰中間的時期被發明出來，很快就流行在所有的螺旋槳飛機上，直到現在所有的飛機螺旋槳但凡能夠變距的，基本用的全都是恆速螺旋槳。在螺旋槳恆速的作用下，無論飛機爬升或下降，飛行速度或快或慢，螺旋槳都能夠自己自動調整槳距，使槳葉與氣流的攻角隨時處在近似定值的狀態。

不過雖然螺旋槳恆速的設計使得槳角可以隨空速而自行調整匹配，但是另一方面，它卻不能夠自行匹配發動機的功率狀態。什麼意思呢？比如說當下整個螺旋槳的狀態都很好，但是我想要加速，於是推了油門，這時會發生什麼事？發動機的輸出功率變大了，槳軸扭矩輸出變大了，於是螺旋槳轉速自然會變快。這時為了使螺旋槳轉速不變，於是恆速機構自動調整，就會把槳角拉高。於是槳葉的攻角就會變大，過量的話甚至能導致槳葉失速！那麼如果我不是要加速而是要減速，收了油門，這時又會怎麼樣呢？這時發動機輸出功率變小，槳軸扭矩輸出變小，螺旋槳轉速會變慢。這時為了使螺旋槳轉速不變，於是恆速機構會降低槳角。於是槳葉攻角會變小，使螺旋槳工作效率降低！也就是說，恆速螺旋槳雖然可以自動針對空速的變化而自適應調整槳距， 但卻無法妥善處理因為發動機功率變化而需要的調整。 當飛行員改變發動機功率輸出，也就是變更了油門的位置時，也會需要將恆速螺旋槳的轉速設定一併調整變更。按照前面對恆速螺旋槳和發動機功率之間所產生問題的推導，可以知道當油門增大的時候，會需要同樣調升螺旋槳的轉速設定，以繼續維持槳葉攻角仍處在良好位置；相對當油門減小的時候，也同樣需要調降螺旋槳的轉速設定。

雖然說螺旋槳恆速的這個機制並不能夠完全免除飛行員對螺旋槳的控制，但其自動化程度已經能相當大幅度的減輕操控負擔。一般飛行時的通常情況下並不需要去做刻意調整介入，只有在變更油門位置的時候才需要一併調整。並且絕大多數時候下，螺距調整桿和節流閥(油門)桿是同進同退的，意思就是油門往前推的時候，槳距桿也同樣往前推；油門往後收的時候，槳距桿也同樣往後收，兩桿子幾乎總是處於同樣的位置 (當然有的時候可能為了短時間得到更多動力，螺旋槳桿會比油門桿更往前些推)。因此雖然仍然免除不了需要去控制螺旋槳螺距，但是控制的對應關係已經大幅度的單純、簡單化了，相比於沒有定轉速的機構而需要飛行員時刻關注空速和轉速，並且持續微調槳距的情況而言，自動化程度已是相當高。

Figure 6. 螺旋槳飛機動力控制的經典三根杆，其中本篇重點在於中間的螺旋槳控制杆 ^[6]

Figure 7. P-51 戰鬥機座艙內，圖中圈起標註的地方就是動力控制三杆，其中寫著一個白色「P」的黑頭柄就是螺旋槳控制器 ^[7]

Figure 8. 一架現代小飛機上面的動力控制三杆，形式或有不同，但操作原理邏輯是一樣的 ^[8]

上面是幾張飛機上經典的控制發動機的三根杆的圖片 (如果飛機有多個發動機的話，那麼這些杆的數量也會同樣增加，每具發動機對應一副)。其中左邊黑色的是發動機節流閥也就是油門，右邊紅色的是油氣濃度控制^[4]，而位居中間的就是本文的主角：螺旋槳控制器(Propeller Level)。 (油門通常都是黑色的，油氣濃度控制器通常都是紅色的，至於螺旋槳控制杆則不一定什麼顏色。 這當中肯定存在某些歷史緣由，只不過我並不清楚其中的典故，而如果有懂行的讀者可以寫信來告訴我。) 注意中間控制螺旋槳的杆並不是槳距控制杆(Propeller Pitch Controller)，因為現在基本所有的飛機都配置了恆速螺旋槳，所以那東西並不直接控制槳距，而是用來調整前面所謂螺旋槳目標轉速的控制器，因此叫作 Propeller Level Controller，或有時候直接簡稱為 Propeller Control；至於中文它叫什麼？也許就姑且稱它為螺旋槳控制器吧！

螺旋槳轉速調控原則

螺旋槳控制器的調控原則是這樣的：「大致跟隨油門，油門要進則它也要進，油門要退則它通常也要退；另外它可以比油門推進的更多，但後退時不能比油門更低。」這項調控原則的前半段應該很容易理解，就如同前面所解釋的槳距調整原理一樣，就是為了匹配發動機功率而已；而此原則的後半段則可能稍微不那麼能直觀理解，它其實是對於螺旋槳控制裕度原理的反應。

前面講解槳距調適原理時就有提過，槳距其實可以有一個操作的容許範圍，偏高則效率高，偏低則動力強；高出太多則可能產生槳葉失速的後果，低出太多則可能產生轉速超速的後果。然而在恆速機制涉入的情況下，基本無需考慮超速運轉的情況，如果螺旋槳真要超轉的話，恆速機制會自動拉高槳距把轉速降下來，因此通常會直接造成比較嚴重後果的是轉速過低的情況！當發動機處在較高油門的工作狀態，功率的輸出較強，很自然的會讓螺旋槳轉的更快，而此時過低的螺旋槳轉速設定，會使恆速機制因為欲降低轉速而過度拉高槳距，便容易發生槳葉失速的問題！於是這就最終產生了「螺旋槳控制杆只能在油門前面，不能落在油門後面」這樣的操作原則，而同樣也是當欲調整油門位置時，「推油門前應先推進螺旋槳杆再進油門，收油門時應先退油門後再退螺旋槳杆」這句操作原則的原理。

已經說了這麼多調整原理，那麼為什麼我們一定要維持槳角、槳距、或轉速在範圍內呢？若槳距或轉速落在容許範圍外面，會發生什麼樣可能的後果呢？當螺旋槳設定轉速過低，也就是槳距過大、攻角過高，則可能發生槳葉失速的現象。回顧機翼升力原理^[9]，當槳葉失速時，氣流會在槳葉背面產生迴流區，這些渦流除了會產生更大的螺旋槳轉動阻力之外，不穩定的渦流也會導致槳葉振動和受力不均，可能造成槳葉損壞或壽命降低。即便沒有到發生槳葉失速的程度，螺旋槳過高的旋轉阻力會導致發動機負載過大，如果這時發動機還處於較低油門的工作狀態的話，就容易造成發動機損壞或壽命降低。這種情況就好比是汽車使用高檔位低速駕駛，或使用三檔起步那樣；省油、效率高是真的沒錯，但車子容易壞也是真的！

另一方面，如果轉速過高……，或者說恆速螺旋槳可能沒有轉速過高的問題，但仍有發動機溫度過高的問題！一般來說除了啟動和暖機的階段之外，通常只有在短時間需要大功率的時候會暫時性的拉高螺旋槳轉速，就好像汽車暫時降檔提速那樣，一般這種操作不會維持太久。一方面是因為此時工況效率差、耗油，另一方面也是因為發動機處在低負載、高轉速的狀態下，容易導致溫度過高的結果。這就和把汽車打在三檔開在高速公路上的情況是一樣的。如果說此時飛機速度很快，散熱條件好的話那可能倒還好，但是若航速不高就可能會有引擎過熱的風險，特別是對於氣冷式發動機而言^[10]！這就是為什麼許多採用氣冷發動機的飛機，在起飛爬升時會被要求不能夠全速運轉，並且要求飛行員時刻注意發動機溫度的緣由了。

為什麼要控制螺旋槳轉速，而不直接控制槳葉攻角呢？

經過前面對螺旋槳恆速機制的說明介紹後，不知道有沒有人會產生一個問題？為什麼我們要設計一個機制去偵測並維持螺旋槳的轉速，而不是去偵測並維持螺旋槳槳葉的攻角呢？你看這恆速螺旋槳時時檢測螺旋槳的轉速，然後透過時時調整槳葉角，去維繫轉速保持在設定的數值，目的是藉此間接的維持槳葉上氣流的攻角不變。那麼為什麼我們不偵測槳葉上的氣流攻角，然後調整槳距直接對標維持氣流攻角呢？這樣不就不存在不同發動機工況下之最佳轉速不同的問題了嗎？不就連螺旋槳控制杆都可以去掉了嗎？那為什麼我們不這麼做呢？

沒錯，其實我們真正想要的目的並不是轉速，而是攻角，並且理想上我們應該直接標定攻角狀態進行控制調整，然而讓我們轉向取道去標定轉速的真正原因其實來自於現實的問題。理想終究太美好，然而在現實的工程上我們該如何去測量螺旋槳的攻角呢？真正導致我們在實務上退而求其次選擇去偵測並控制轉速的原因，其實是因為轉速相對容易測量。對於測得螺旋槳的轉速，傳統上只需要使用一個離心調速器^[11] (如圖 Figure 9)就可以了，甚至在現代電子元件科技的加持下，也許更先進的飛機可能使用光學感測器來測量；但是槳葉上的氣流攻角要怎麼去測量呢？並且這個測量的方法還得要是在高轉速、大離心力的螺旋槳上面，可以可靠、穩定、且經濟的測量槳葉攻角的方法！這就是為什麼最後流傳下來的控制機制不是標定槳葉攻角，而是標定轉速的原因了。雖然這個方式遺留了一些未能妥善解決的問題，也就是在不同發動機工況下的最適轉速不同的問題，但對於減輕駕駛員操作負擔的這個目標來說，其省心程度已經相比讓駕駛員直接調整槳距的原始方式來說提升了一個層次。

Figure 9. 離心調速器 ^[12]

其實類似這樣因為現實困難而妥協的設計經常出現在我們日常所見的事物中。比方在活塞發動機主題裡就曾提及過 ^[5]，為了點火正時的問題，我們真正需要的其實是在活塞抵達上死點之前一個固定的時間執行點火。我們真正需要與想要的其實是對於點火時間提前量的控制，然而現實上卻因為時間的偵測與同步問題，使得我們不得不退而求其次，改為控制點火提前的曲軸角度，並且因此留下了在不同曲軸轉速下所需的最佳提前角不相同的問題。

總結

本篇以螺旋槳槳距調整為核心，講解了調整槳距的目的，即讓螺旋槳適配氣流的狀態，使槳葉總是處於最佳效果的角度。在可正常工作的槳角範圍內仍存有可微調的空間，可依據效率優先或馬力優先的需求調整使槳角偏高或偏低，並且對於槳距的調整機制可以類比為汽車上的排檔變速行為。除了正槳之外，反槳能使飛機在地面上的操作更加靈活，而順槳則能在空中停車時減少螺旋槳帶來的阻力。在槳角調整適配的理論原則之後，介紹了已被廣泛大量使用的恆速螺旋槳機制，它的存在能夠相當大程度的進行自動化控制並解救飛行員於細碎的操作之中。並且解釋為什麼採用轉速進行間接控制，而非直接針對槳葉攻角進行自動化控制的原因，是源於對工程現實妥協的結果。

螺旋槳 1：原理簡介

Sat, 24 May 2025 22:56:27 +0800

在有了一臺能夠提供強勁動力的發動機之後，我們還需要將旋轉的軸功轉化為真正前進的推動力量，這東西在汽車上叫作輪胎，而在飛機上便是本系列的主題：螺旋槳。

Figure 1. 螺旋槳透過旋轉的力量將空氣向後推出而得反作用力 ^[1]

螺旋槳的作用就是將軸的旋轉力量轉變為推動流體(空氣)向後吹的力量的設備。它的原理就和我以前介紹過的機翼升力原理 ^[2] 是一模一樣的，差別在於一個是平移、一個是旋轉。機翼是靠著飛機自己的快速往前跑來讓機翼切過空氣，並將相對氣流折轉向下，而螺旋槳是靠著自己旋轉起來快速切過空氣，將空氣向後壓。螺旋槳的工作原理和機翼一模一樣，這個意義表示我們可以完全沿用從前對機翼原理的理解，連相關的計算圖表與分析工具等都能夠同樣套用在螺旋槳上面。

此外在我們日常見聞之中，其實存在非常非常多那些我們可能不將它們稱呼為螺旋槳，但原理和螺旋槳一模一樣的東西。不過雖然螺旋槳的種類和應用用途不少，但本系列將聚焦探討的是那被使用在固定翼航空器上面，用來給飛機提供推進力的螺旋槳，也就是一般所謂螺旋槳飛機的螺旋槳。

Figure 2. UH-1 直昇機頭頂上巨大的旋翼 ^[3]

Figure 3. V-22 魚鷹機頂上可傾斜的，既當直昇機旋翼用、也當飛機螺旋槳用的巨大旋翼 ^[4]

Figure 4. 在輪船上安裝的巨大船用螺旋槳 ^[5]

Figure 5. 生活中隨處可見的電風扇 ^[6]

歷史

Figure 6. 阿基米德螺旋泵 ^[5]

在有記載的西方技術演進史中，現代螺旋槳在古代最早的雛型大概就是在西元前 200 年，阿基米德的螺旋泵了(如圖 Figure 6)。螺旋泵在當時被用來抽水使用，而同樣結構的東西直到現代也仍然被許多應用領域使用，如塑膠射出成型設備的加壓器等。

後來使用機械動力的蒸氣船舶被發明出來以後，螺旋泵很快也被嘗試使用在船舶上作為推進動力裝置使用。只不過在船上的使用情況與陸地上抽水不同，通常不會產生大範圍的位能變化，很快人們發現其實只要取用螺旋泵的一小截就可以了，剩下多餘的部份並不能夠再產生更多的動力，只會變成阻力累贅。於是在螺旋槳剛上船的那個時期，基本就是短短一小截螺旋泵的樣子(如圖 Figure 7)。直到近代早期的螺旋槳仍然能見到延續這個概念的影子(如圖 Figure 8)，不過此時螺旋槳形狀的發展也已經相當接近於我們現代人所理解認知的樣子了。

Figure 7. 1843 年某條船隻所使用的推進裝置，其實就是短短一小截的螺旋泵 ^[5]

Figure 8. 1845 年的 SS Great Britain 螺旋槳，基本延續最後一截螺旋泵的結構 ^[7]

從船上來到天空，除了模仿鳥類揮動翅膀的概念設計之外，最初見比較正經的升力機構大概就是在 1480 年代，達文西所設計的的直昇機了(如圖 Figure 9)！從達文西的直昇機設計圖中我們依然明顯可以發現，他的「空氣螺釘」(也就是我們現在所理解的螺旋槳)，基本就是將螺旋泵轉個角度垂直使用而已。不過如果脫離西方視角的話，其實在古老的中國，大約西元前 500 年就已經一步到位發明了與現代意義的螺旋槳一樣的設備：竹蜻蜓(如圖 Figure 10)。只不過可惜中國人的發明似乎僅止步於將它作為玩具使用，並沒有再繼續取得更多的進展。

Figure 9. 達文西直昇機 ^[1]

Figure 10. 竹蜻蜓 ^[1]

槳截面氣流

Figure 11. 在螺旋槳一處槳葉截面上，其裝置角、氣流、與攻角之間的關係 ^[8]

讓我們聚焦在螺旋槳的其中一隻槳葉的其中一處截面來觀察，那麼槳葉截面與推力線和氣流之間的關係大約就可以表示如上圖(Figure 11)所示。

在示意圖的定格畫面中，槳葉正好旋轉到這個位置，正在往下運動，而這個運動是由轉軸轉動螺旋槳所造成的，也就是圖中(Figure 11)以粉色標示為 Rotational Velocity 的箭頭。也就是說以槳葉的視角來看，有一股與它自己的運動速度一樣快的氣流正在反方向(由下往上)朝它吹來。由於槳葉本身帶有一個傾斜角度，也就是圖中以黃色標示為 Pitch Angle 的角度，因此槳葉在氣流的作用下會產生升力(推力)和阻力。槳葉產生的升力就是我們所謂螺旋槳產生的推力，也就是圖中以藍色標示的 Thrust 箭頭；而阻力就會變成螺旋槳轉動阻力的最大來源 (螺旋槳轉動阻力還包含很多，如轉軸摩擦力等，不過它們與氣流造成的阻力相比之下微不足道)，此阻力則由發動機所提供的轉矩來對抗，以維持螺旋槳持續轉動的能量。

由此可見，螺旋槳產生推力的原理就和機翼產生升力的原理是一模一樣的，只不過在畫示意圖的時候，一般機翼升力朝上，而螺旋槳升力(推力)朝側，方向不同而已。另一個不同就是飛機機翼是持續往一個方向移動，而螺旋槳是轉動的，但是在關注於一個極短的時間片段的情況下，如上面示意所描述的樣子，則兩者並沒有根本性的差異。因此對於螺旋槳產生推力(升力)和阻力的理解，完全可以回去參考我往期寫過的主題 ^[2]，這裡就不再花篇幅詳細解釋。

此外對於螺旋槳氣流，還有一項同樣重要的特性需要說明。由於螺旋槳在運作的時候，通常我們的飛機也同時在移動，也就是上面示意圖(Figure 11)以藍色標示的 Forward Velocity 箭頭。因此螺旋槳所感受到的相對氣流並不只是單純由 rotational velocity (粉色箭頭)產生而已，而是 rotational velocity 加上 forward velocity 所合成的氣流，也就是圖中以綠色標示的 Relative Wind；因此槳葉與氣流的相對夾角(也就是攻角)並不是圖中標示的黃色 Pitch Angle，而是綠色的 Angle of Attack。

Note	為了避免不必要的複雜度，這裡我們假設飛機前進速度的方向和螺旋槳的推力方向是相同的，不存在兩者之間有夾角的情況。並且在本系列主題中都將延續這個隱含的假設條件，也就是說除非有特別說明交代，否則都默認不存在帶有側滑的情況！

所以槳葉的實際氣流攻角會比它自己的裝置攻角還要小，至於多小則不一定了，得視飛機前進的速度(以下簡稱為飛行速度)和槳葉旋轉運動速度之間的關係而定。那麼在適當的情況下，槳葉攻角就有可能是負的，也就是雖然螺旋槳還在旋轉，但不只不能產生推力，反而還產生阻力！另外，螺旋槳葉片既與機翼相同，自然也同樣存在上表面氣流分離，也就是槳葉失速的情況，當攻角夠大的時候就會發生！

此外，不同於飛行速度所產生的氣流在整個螺旋槳盤面都一致(暫且拋開誘導氣流)，槳葉移動的速度是隨著槳盤面半徑位置的不同而變化的！白話解釋就是在同樣的轉速之下，愈靠近軸心的地方移動速度愈慢，而愈靠近槳葉尖端的地方移動速度愈快，如下圖(Figure 12)所示。那麼槳葉截面最適合(不過大也不過小)的攻角在整根槳葉的不同位置就是不一樣的了！而這就是為什麼大多數螺旋槳槳葉會製造成扭曲形狀的原因，如下圖(Figure 13)所示。

Figure 12. 螺旋槳槳葉的移動速度在不同的半徑位置上是不一樣的，愈往中心愈慢，愈往外圍愈快！ ^[9]

Figure 13. 槳葉不同位置截面的安裝角不同 ^[1]

其實除了飛行速度本身產生的相對氣流這個因素會使得螺旋槳槳葉有效攻角減小之外，螺旋槳自己產生的「誘導氣流」也會進一步減小槳葉有效攻角。但是有關誘導氣流的部份不論成因、解釋、還是計算都比較複雜，並且其影響在大多情況下可能不若由飛行速度所產生的影響來得更大，因此暫且空置這個部份，待到後續合適的主題時再來解釋其成因和影響，並在進階主題時才對其進行計算。如果讀者甚至不明白誘導氣流這個詞大概是個什麼意思的話，那麼可以暫且當作這東西不存在！

槳距

如果接觸螺旋槳飛機夠多的話，我想一定經常聽到「槳距」這個詞。但槳距是什麼呢？

Figure 14. 螺旋槳槳距定義示意 ^[10]

槳距的定義其實就是直接套用螺絲的「螺距」。也就是說假設螺旋槳不是在空氣中旋轉，而是在果凍中緩慢旋轉移動，不帶任何打滑的話，那麼槳葉的安裝角就會使螺旋槳像螺絲一樣帶著槳盤前進一段距離。當螺旋槳旋轉整整一圈的時候，盤面前進的這個距離就是槳距了，與螺絲的螺距一模一樣，如上圖(Figure 14)所示。

不過其實槳距的定義嚴格來說意義並不大，其目的更多的是給操作者(通常也就是飛行員)一個可以參考的大小而已！這麼說有兩個原因，其一是螺旋槳運作在空氣中，本身條件就和輪胎、螺絲等應用場景大相逕庭，其「打滑」的情況司空見慣，以至於將槳距對應到真實的飛機前近距離並沒有實際的參考意義；其二是整片螺旋槳不同位置的安裝角可能是不一樣的，它們的「螺距」可能互相並不一致，那麼又應該以誰為準呢？因此槳距這個詞其實意義更大的部份是在於幫助對螺旋槳某些特性上的理解，在實際操作應用上，其確切之數值亦無任何絕對性的意義，而是利用其相對的大小關係來給予操作者對於當前狀態的理解。

雖然槳距、螺距這兩詞在學理上效用不大外還有模稜兩可的空間，並且在工程和理論分析的用途上往往更有用的是直接定義每個截面位置的葉片角度，但由於它能夠非常簡單直覺且傳神的表達槳葉當下的配置狀態，因此在整個螺旋槳整體的視角之下，我們便仍然經常使用這兩詞來傳達一個相較模糊大約的螺旋槳狀態。那麼為了精減文字的緣故，也為了符合常見慣例，本系列文章也會經常使用這兩詞語。

在前一節我們已經知道了螺旋槳自己切過的氣流、加上因為飛機前進的氣流後的合成氣流，以及槳葉裝置角之間的關係，那麼許多問題就來了。首先是因為圓周旋轉的關係，一片槳葉在不同位置上的實際移動速度是不一樣的，這就導致槳葉不同位置的合成氣流角度是不一樣的，那麼螺旋槳要如何製造才能夠讓每一個位置的氣流攻角都是最適當的角度呢？這就是為什麼我們一般看到的螺旋槳槳葉都是扭轉的形狀的原因了(如圖 Figure 15)。這樣扭轉槳葉就能讓整片槳葉的每個位置都處在最適合的攻角之下。

Figure 15. 一戰時期飛機上的螺旋槳，注意槳葉扭轉的造型 ^[11]

但是除了上面的問題之外仍然還有其它的問題，比如隨著飛行速度的不同，也會導致槳葉氣流的角度改變。用白話文來說明就是在不同的飛行速度下，其實槳葉的最適合攻角也是不一樣的。那麼如何解決這個因為飛行速度不同而導致螺旋槳槳葉安裝角度需求不同的問題呢？解決方案主要有三種：

取捨折衷。也就是將槳葉扭轉角度設計適配一個最重要的飛行速度，至於在其它飛行速度下肯定表現會比較差，不過就算了！這是從萊特兄弟開始就一直採用的方案，直到變距螺旋槳發明之前都被大量使用(如圖 Figure 15)，就連到了現代也仍被用在許多低成本的用途上。
主動調整控制轉速以適配飛行速度。也就是說，當飛行的速度不一樣的時候，我們就透過改變螺旋槳的轉速去適配。這樣當飛機飛得快的時候就讓螺旋槳轉快一點，飛得慢的時候就讓螺旋槳轉慢一點，使槳葉攻角永遠保持在最適當的條件下。這方案看似很無厘頭，然而確實存在並且有應用價值，比方說當代渦輪發動機內的壓縮機葉片就是以這種方式來適配不同的氣流速度的。
採用可變距結構。如圖(Figure 16)所示，將每一片槳葉設計為可改變扭轉角度的結構，這樣在任何的飛行速度與任何轉速下，都可以透過機構去改變葉片的裝置角度，使得氣流總是處在最適當的範圍。這種螺旋槳也是從二次大戰前一直到現在，主流螺旋槳飛機所大量採用的設計方案。當然這種看似最完美的方案也同樣有其缺點，例如結構較為複雜且成本較高，對於承力結構的安全性也有一定程度的要求 (因此在許多地方的法規裡並不允許輕航機使用這種螺旋槳)。

Figure 16. C-47 上使用的變距螺旋槳，注意槳葉本身不只有者扭轉的造型，其圓柱形的根部也是可以經由控制機構來改變轉角的

Figure 17. 可變螺距螺旋槳示意 ^[12]

利他行為

Sat, 17 May 2025 11:22:28 +0800

觀察人類的許多行為或心理活動，往往能夠發覺很多不容易想明白的迷惑傾向，例如其一就是利他行為。顧名思義，利他行為就是對他人有利的行為，不一定對自己有利，甚至許多時候是對自己有害的。那麼這種行為符合科學與邏輯嗎？對於這些不了解的奇幻心理活動，除了以「愛」之名打發過去之外，還有沒有其他的邏輯解釋？那麼本篇就來討論有關利他行為與利他心理的箇中奧妙。

人類經常會做出很多乍看不利己的行為，比方謙讓、扶助弱小殘疾、節衣縮食省下來捐助給貧困者等等，這些行為都是對他人有利而對減損自己利益或生存資源的。有些行為比較大，例如捨命救人、捨己救子等等，為了自己以外的別的個體的好處連自己的命都能犧牲。當然還有更多的行為其實不會動不動捐獻性命，這些行為對自己的犧牲是更小的，卻也更常見於生活之中，例如禮讓別人優先排隊、優先挑選食物或商品，或是在便當不夠的時候讓給其他人而自己餓一餐，或甚至像停等紅綠燈讓別人先過馬路等等都算。作為高等靈長類的人類可能對於這些良善的行為並不覺得特別意外，但大多數可能也並不了解其中的緣由，當然可能大部份也不認為有了解的必要，於是自詡星球唯一高等文明的我們便往往簡單的將其歸類於善良的公序良俗，或者更簡單的歸於因為人類有「愛」！然而若是這麼簡單就把這個問題給結了並不符合我的風格，作為講究科學和邏輯的部落格主，我們得試試看能不能從生物演化學的角度來解析，看看這些損己利人的事情背後究竟有沒有什麼邏輯脈絡可循？

如果我直接打開天窗說亮話，告訴你所有一切都是利己，所有看似利他的行為全都是為了利己的目的而行的，你信嗎？

一切本於私利

在我所舉例的這些利他行為裡面，其實有一小部份的行為是相當容易被直觀理解的，比方說孩子的母親父親為了保孩子而犧牲自己。這是因為從生物生存繁衍的角度來說，孩子是自己基因的延續，當發生意外的災禍而必須有人要遭殃的時候，顯然把生存的資源和機會留給後代是更加有利的！當然從演化的角度來看，同樣我們可以理解在從前肯定存在許多做法不同的父母，有捨己救子的，也有捨子保己的，只不過後者在漫長的演化過程中可能都已經被吃完了，以至於不容易在億萬年後被我們遇到！然而除了這種對自己的後代直接相關的很容易被分析理解之外，在日常社會中我們所能看見的大部份利他行為，卻可能比較難以和自己的利益明顯的連結起來。在我們一生回憶中的許多利他不利己行為，可能更多的受益方是朋友、同學、同事，還有更多可能是不認識的陌生人。那麼為什麼這些行為傾向並沒有在漫長的演化過程中被淘汰掉，反而還發展成為人類天性的一部份呢？

這些各種表面看似犧牲了自己的利益，減損了自己的生存資源和機會的行為，乍一看好像違反了演化論的邏輯。然而我直接先告訴你答案，這些所謂的各種利他行為其實都是利己的，是完全符合生存繁衍策略的演化優勢；或者有時候我會更喜歡這麼說： 包含人類在內的所有動物，總是為了自己的最大利益而生存，一切本就都只有利己而已。 因此人類的各種捨己利他性才會在漫長現實而又殘酷的演化道路上不只被保留下來，還被進一步強化。

為了徹底理解這當中的原理奧妙，先讓我們從比較直覺的一般概念來起始。對於單一一個個體，也就是你、我、他，或者任何一個人的他自己來說，如果從非常直覺直觀的角度來看，我們要如何取得自己的最大利益呢？或者說，我們能夠如何最大程度的滿足自身的生存、溫飽、舒適、和繁衍等目的呢？那肯定是什麼都不讓，全部我都要；管你們東西夠不夠反正我要拿夠，管你們排隊不排隊反正我來就要直接插第一，管你們其他人去死去活，反正我要拿夠拿滿吃飽喝足；什麼垃圾不落地、環境資源永續、長幼有序、先來後到、還是紅燈停綠燈行，我又不認識你們，我方便我滿足就好；什麼誠信原則、什麼契約精神、什麼信賴、什麼承諾，我就反悔了你耐我何？對於上述形容的這麼樣一個徹頭徹尾極度自私自利的人，理論上應該要很有生存優勢對吧？然而實際上會發生什麼事呢？ 當一個個體極度自私、極度自我中心、極度利己的時候， 那麼對於這個個體以外的其他所有個體來說，那就是極度的不利己。 於是對於所有其他的任何人來說，和這樣一個人合作顯然就是最不利的選擇，是極度減損自己生存繁衍利益的事情！於是所有其他人會拒絕、孤立、和排斥這麼樣的一個極度利己者。那麼視角回到上面這個極度利己者的身上，請問這些行為總體效果終究是給自己帶來了最大的生存繁育演化優勢，還是帶來了極大的劣勢呢？

於是本篇的主題到了這裡已經豁然開朗。包含人類在內的任何生物，但凡需要兩個以上個體合作乃至多個個體組成社會的，都脫離不開彼此的需要，而任何極度私利自我中心的個體會得到的結果是被他人排擠的極不利局面。因此 利他性的本質，其實就是藉由犧牲讓渡自身的部份利益或優勢， 去換取其他個體的合作意願，或交換群體的接納包容，最後會反過來從之得到更大的利益回饋！ 也就是說其實是透過犧牲部份利益來得到更大的利益，看似會減損自己生存繁育利益的事情反而能夠曲線給自己得來更強大的生存繁育優勢，於是這些利他性的行為其實就是一種著眼更大收穫的投資付出行為。

到這裡其實就已經把利他性的核心原理全部解釋完了。這就是為什麼人類即便在沒有接受所謂文明開化的教育之下，往往也能夠本能性的發揮出各種利他行為的原因。比方說會本能性的對他人友善，對身於苦難狀態的其他人心生憐憫而產生救助之意，禮讓幼小、同情弱勢、服從團體規範，以及對各種自認不公義的事情義憤填膺等。雖然這當中確實存在許多文明教育之下的影子，然而仔細觀察審視便不難發現，許多的行為、傾向、和情緒其實是天生的，是任何即便未受過知識教育和文化薰陶的人都能夠天然擁有的性質，而這就是這些行為認知已經刻入 DNA 的演化天性的證明。當然，並不是每個人都能對這些事情在知識上具有足夠程度的認知和理解，於是我們可以觀察到大部份的人們對於人類經常會表現出許多無法理解的迷惑行為，而因為無法解釋，於是人們便習慣性的將它們歸於「愛」！ (當然我並不是說愛就是這些，只是說明所謂的愛裡面至少包含了這些。)

其實類似人類所理解的這樣的透過讓渡利益來獲取合作利益的情形，在許多其他的動物裡也同樣能夠看見，特別愈是群居有社會性的動物愈是明顯。事實上即便在跨越物種的情況下也並不少見這樣的現象，我們一般會稱之為「互利共生」。

私利最大化

經過前面的解釋說明，有沒有對於許多人類、乃至各種群居動物的一些看不明白的奇幻行為有種豁然開朗的感覺呢？不過肯定也會有很多讀者到這裡或是質疑也好，或是產生新疑問也罷，總之急切著想要立刻提出另一些並不符合我前面所描述的現實觀察，即是那些並不符合他人或群體利益，純粹是損人利己的行為。對這部份，請聽我娓娓道來。

其實一個個體生存生活在世界上，各種環境、生態等條件是非常複雜的，這些複雜的變因產生更加複雜和奇幻的真實世界，使我們在每一個了解的當下常嘖嘖稱奇；然而更常令我稱奇的是在這極度複雜炫麗又奇幻的真實生物世界下，背後的核心原理和邏輯卻又是那麼的簡單純粹，一切的一切就是圍繞著兩件最重要的核心利益而展開的：生存，然後生殖、繁衍。

想像一個畫面，現在我們處在一個理想中完美的合作社會。人與人，所有的人與人之間互相扶持，互相幫扶；人人都為了人人犧牲自己的利益，然後人人都從人群那裡獲得綜合更大的利益，一切欣欣向榮、歌舞昇平。這樣的想像會太抽象嗎？那麼具體一些就是人人都尊紀守法，紅綠燈會停、弱小會幫、貧困會扶、病殘會助，講究榮譽、不偷不搶、看重信用、承諾必達、公平公正、童叟無欺。教條也好、信仰也罷，總之人人都以這樣的信念生活和互動。當然這樣的行事模式讓群體內的每一個個體都蒙受一定程度的個人利益減損和犧牲，然而我們知道最終每個個體也會從整個群體得到更大的回饋，獲得那相比的犧牲付出更大更豐的綜合利益回報。這一切都是那樣的美好，整個社會彷彿身在烏托邦似的夢幻狀態……

好的，現在讓我們的思緒仍舊處於這樣一個美好的烏托邦社會，但是將焦點放回其中單一的一個個體身上。對於單獨的一個生物個體來說，還有沒有什麼能夠再收穫更大個人利益的可能？是不是又豁然開朗了呢？當大家都尊紀守法的時候，我就喜歡闖紅燈，這樣不用傻傻枯等，而且反正被嚇到的其他人也會讓；當人人都紅線不停車的時候，我就喜歡把車子停在家門口的紅線上，不只方便，而且因為別人都守規矩，所以一定是空的給我停；當大家都輪流排隊一個東西並且用完就趕快還的時候，我就喜歡一直佔著不還，直接拿回家去就變成我自己的，一個不夠用就再拿幾個，反正缺了會有人補貨，補完我再拿；當大家都一言九鼎的時候我可以方便的得到別人承諾的回報，但當你要來叫我兌現以前的承諾的時候，那就是時空環境不同了，以前的事情我哪會記得呢？而且你有錄音嗎？有白紙黑字為證嗎？

是的，儘管我們認為這樣的人相當無恥，然而站在個體最有利益的角度來看卻是對個體最有利的方案！這就是為什麼我們內心總是有所私心，並且在億萬年的演化史之中並沒有消散的原因。雖然每個人都犧牲一些拿出來貢獻給別人，最終可以得到物超所值的回報；但是 在其他每個人都合作付出的前提下，某個單獨的個人卻只以私利為重，這才是真正能夠搜刮最大利益的生存法則！ 與他人合作或多人的團體社會就如同經典囚徒困境所描繪的那個情況一樣， 真正對自己最有利的夢幻方案並不是讓所有人都信守道義保持沈默， 而是在大家都忠誠不二的情況下我卻背叛並指控他們！

至此應已能理解那由億萬年的生存法則演化歷練而來，深埋於每個人(及一切動物)身體深處，互相矛盾卻又同時存在的兩項天性特質，即利己性、和利他性。其中的利己性本就直接有益於使我們更能在艱難的生存繁衍道路上搶奪資源，而合作的社會環境卻使我們犧牲利己並改以利他來獲得單獨一個人不能得到的更豐厚回報，實為曲線利己；然而在普遍利他的情況下保有並發揚利己性卻能更加有益於最大化收割生存繁衍的資源。因此在漫長的演化道路上，利己、利他這兩者並沒有誰戰勝了誰，而雙雙都被保留並同樣的強化下來，共同存在於我們每個人的心裡。這些是天性，所謂天性就是即便沒有學習、沒有文化，即便回到蠻慌時代，每個人依然生來就會自然擁有的內心「感覺」。

這種不用教就自己存在的天性，其中的利他性大概就是古人所謂的「人性本善」的成份吧；而利己性就是「人性本惡」的部份了。那麼人性到底本善還是本惡呢？在古時候這可能是個能讓人爭論多年的問題，但是在現代我們有演化科學的邏輯分析之下，幾乎已經可以斷定人性是本善亦本惡，二者皆有之，只要在合適的情況下就能讓其中一部份展露出來。

社會的調適

前面說明的利己性和利他性主要都聚焦於單一一個個體身上，即便在說明犧牲和利他的時候，也是以單一個體所獲得的投資回報為著眼點。但若把視角放開看向更廣泛的群體，或者白話說就是關注一下那些「其他人」，就不難發現零和遊戲的矛盾衝突！

懲戒

站在個體利益來看，大家都犧牲奉獻唯我營私苟且那當然是最好的；但是站在以外其他人的視角來看，這種情況顯然是對自己非常有害的。不過這些情況他就是自然會發生的事情，因為符合生存演化的最佳化策略，因此總是會有人這麼做或想這麼做；只不過讓少數個體利用群體來搜刮資源，對於其餘的他人顯然是非常不符合生存演化邏輯！那麼一個社會，或者說就是這些利害相關的「其他人們」，對於這樣不利己的情況又會有什麼樣的反應應對呢？

面對所描述的這種情況，人們首先會使用的方式便是「制裁」。這個是指廣義各種型式的制裁，包含大到社會組織所實行的強制行為如拘補監禁等刑罰，小到我們對於那觸犯「道理」之人投以怒目圓瞪的眼光。制裁的作用在於給予想要偷雞摸狗之人足夠的威嚇力，使他在想要做出那些傷害群體利益之事前先惦量一下後果，小到承受他人的情緒壓力，大到被人群的力量強制行為反制的結果。自私自利不管他人的根本原理不就是因為這樣能得到更多生存資源嗎？那我就來給你人為減少生存資源，讓你無利可圖還得倒賠！於是小從情緒壓力、罰款、監禁、用刑、到死刑，原理無不就拆毀營私舞弊的獲利空間，甚至一個死刑如果還不足以形成足夠的威嚇懲戒力的話，還可以連坐將你的後代一起送走，為的就是維護團體的共同最佳利益，或者我們可能會稱之為「規矩」。 (當然也有很多歷史上的懲戒是為了取得屬於一個人的最大利益，但那其實已經屬於領導統馭的話題了！)

避免懲戒

我在解釋前面東西的時候，經常會容易遇到質疑。他們認為人與其他物種不同，因為人有「愛」、有「道德」，並且質疑生物本性的說法只不過是私利行為者為了給自己找開脫的藉口而已。且不說這些他們自己也道不明白的愛與道德的內容其實就是曲線利己的部份吧，現實上確實真實存在許多不管不顧這些並且極度自我中心的利己行為者，而他們大多現在在監獄裡！這就是群體制裁效用的真實展現。演化理論往往是相生相剋、環環相扣的，人性底下不只同時擁有惡魔(利己)和愛(利他)的部份，還有威脅他人應該要發揮有愛的部份(制裁)，以及也同時擁激勵自己自發有愛並對抗內心惡魔的部份(趨利避害)。於是你會發現，人的內心不只存在制裁他人的本能，還有畏懼被制裁的本能。

先不論那些強制性的制裁行為，為什麼即便是展現生氣的樣子，即便只是眼神用力瞪過去的行為，理論上完全無法對他人實質造成損害的行為，卻能夠發揮出制裁的效用呢？因為對於個體來說，受到制裁是極為不利的，是對自己的生存和繁衍可能會帶來毀滅性打擊的威脅的；即便沒有實質性的被反向掠奪，光是不再受到團體的包容庇護的威脅就足以造成個體利益喪失，因此我們對於被制裁、或者可能會被制裁的徵兆才會產生本能性的恐懼。就如同我們會懼高、會怕黑一樣的自然，那埋在人類心底深處的恐懼也包含了被排斥、被不接納、被不認同的恐懼，這一份恐懼讓人在察覺到旁人已經有些怒火中燒的跡象的時候適當的收斂，讓人在意識到可能會遭受群體意識的反撲時惦量一下自己有沒有足夠對抗的本事？而當然，既然屬與天性的範疇，就表示這些權衡利弊的估量活動不一定有經過大腦的表層意識，而可能大多時候是你的身體已經快速計算惦量完成了，然後透過情緒、或所謂的道德感，告知你的大腦現在該如何進行下一步。因此人與人組成的人群不只會嘗試去制止和懲罰那些過度私利的人，每個個別的人內心也同樣存在避免淪落到接受懲罰的天性意識。對於群體來說，這樣的生物特性是有利於族群的，因為這樣社會能夠不需要使用高成本的方式去強制「教育」改變每一個脫序的行為，而是可以使用比較低成本的威嚇，或者更低成本的基於情緒的「提醒」，讓個體在剛剛萌生想要搞怪的心思的時候，就能夠早點知道該自發性的自我審視懲戒，並且自發性的展現出「愛」。

當然這只是大部份的個體在大部份時候的情況，然而「鋌而走險」的天性同樣也存在於人性裡，畢竟有時候若賭對了，確實能給自己帶來相當的收益回報。對於這樣的事情，群體組成的社會就會適當的給予反擊，也就是即時的給予對應的懲戒報復。對於違反社群利益的脫序行為是需要合適的給予對應的反擊的，這不只是為了奪去那投機取巧期望收穫的利益，也同樣有著提示的作用，警醒那些其他可能也有相似想法萌生的人，讓大家自發性的知道自己原來是「喜歡愛與被愛」的！這一點是非常必須的，若社會不能夠對於脫序行為給予實質性的懲罰反擊，若群體失去了這樣的威嚇力，那麼社會就會逐漸演變成另一種情況，這點我們留到下一節再論。

這就是為什麼我們天生存在悲天憫人心理意識的原因了。比方說當我們看到新聞，無辜女孩被歹徒強暴殺害、孩童或嬰兒被虐待至傷、孤苦弱勢正在承受災禍等，我們會從內心產生出悲憫的感覺，促使我們嘗試去以各種手段介入。從嚴格來說，這些受害者多半與我們並沒有直接的關聯，也不是我們的直系血親，或至關重要的情感連繫者，但我們依然能夠對其產生情緒的起伏並且萌生呼籲介入的渴望。這就是演化而來的群體意識的一部份，底層生物邏輯就是因為群體的利益或者「規矩」被損害了，而我們的天性驅使我們試圖去維繫這份利益和規矩。從消極面來說是懲戒兇手，給予對價剝奪並警示其他可能的恔仿者；從積極面來說是希望能夠發揚群體優勢去扭轉在群體內遭逢不幸的個體，因為誰都有可能某一天會同樣需要得到群體力量的扶持，因此維繫這樣的生態同樣曲線利己。

和平與動亂

尋求合作與自私偷利是同時存在於人性裡面的底層動機，而那個別人物對於獲取更多自己的私利而損害到群體的部份，則有賴於群體的反制措施來予以導正。然而群體的力量並不總是這麼靈光的！在人類的歷史過程中我們經常能夠看見，因為各種各樣因素導致群體的約束力式微。天災或人禍、疾病或飢荒、戰爭與動亂、征服與被征服、或者是源於社會組織本身的僵固或腐敗，具體的原因其實不太重要，總之導致了群體維繫道德與正義的約束力失去了它的威信，或者有時候經常根本就是一團混亂。那麼這時候群體、以及每一個個體，對於利己和利他之間會不會發生什麼消長呢？

經過一系列基於演化原理的說明，我們知道人性的根本就是服務於每個個體的生存和繁衍目的，一切衍生的天性都是最終為了這兩目的服務的，只是直接、間接、或曲線達成的差別而已。當社會不在有能力對違規做歹者施加反制力量的時候，關於人性會如何轉變的這個問題，應該已經答案明顯了！當直接利己者不會遭受懲罰剝奪，那當然就沒什麼後顧之憂了；當道德利他者不只得不到回饋，反還直接損失利益與優勢，這樣的人自然難以生存和繁衍；當其他本不屬於前述兩者的人親眼看見誰受好處而誰受壞處，那麼再愚笨的人也自然都知道好與壞、利與弊。於是人們會逐漸走向擁護私利，也就是一般白話所謂的道德淪喪。 那麼當你的私利和他的私利相衝突的時候怎麼辦呢？弱肉強食嘍！ 「你不講道義、他不講公理，那難道是我活該做白痴嗎？！」「大家都只顧自己，不顧大局，何者只有我在思慮大眾的利益？那行啊，都別活了！從今開始就各憑本事，拼拳頭嘍！」這時候就會變成實力至上的豺狼虎豹時代，所有利益靠誰拳頭更硬來爭取，生存繁殖就是比誰更陰險狡詐。反正人類已經在叢林法則中生存了億萬年，沒什麼不好適應的！

這就是為什麼社會必須極力維繫在現在很多人眼裡被視為虛無飄渺的「道德」等公序的原因，因為一旦社會不能維繫正義，那麼人心的惡魔就會逐漸佔領上風處，直至使社會瓦解。然而其實也無需過多擔憂，因為這樣的事情在人類的歷史上已經有過千萬次了；而只要地球不毀滅，應該未來還會再發生千萬次！

但是人畢竟不是像老虎那樣能夠單打獨鬥的生物，人類終究視需要依靠其他同類的合作來共同生存的，因此當事情發展到互信互助的連繫被完全摧毀，個人全憑自己本事的情況，其實對誰都沒有好處！於是你就會發現，當混亂蠻橫到了一定程度之後，就會有人跳出來鼓吹愛與包容、犧牲與奉獻。 直白的意思就是：「大家各自為戰最後誰也活不下去，誰都撈不到好處。不如我們各自退讓點，每個人都犧牲一點點自己的好處，這樣我們可以互相合作妥協，這樣對每個人都好。」

於是新的秩序會重新被建立起來，人們也會逐漸發現互利共生對大家都好，然後緩慢的發展成熟一個新的穩定合作結構，重新找回友愛、包容、自律、信任、與責任，一切都逐步邁向美好光明的未來……。當然在相對完好的社會結構下，自然而然就會有人想要偷雞摸狗試圖取得屬於自己的更大利益，而整個社會也會與他們開展一場場貓捉老鼠的遊戲，以維持社會的規矩和風氣；直到那天這個社會又力不從心，壞人享果實、好人享墳墓，那麼慢慢的每個人又會再度找回那深埋於自己身體裡卻已被遺忘的，從遠祖輩就流傳下來的生存法則……。就這樣周而復始、不斷輪迴，綜觀各地各民族的人類歷史基本都是這麼不斷反覆的！

這就是為什麼利己和利他、惡魔和天使經歷過漫長的演化道路之後卻沒有誰能真正勝過另一個， 並且未來應該同樣也是誰也無法消滅誰的真正原因了。因為這東西永遠走不到一個真正的穩定，其所依賴的生活環境不斷在變化和輪迴，導致我們永遠需要這兩者的同時存在，來為我們每一個個體的最大利益做出貢獻。而這種互相矛盾而又同時存在的天性傾向，落實在我們的生活中就是如何調和拿捏進退消長的課題，並且這種行為活動可能大半是在身體的意識裡演算完成的，而不是在有意識的腦子裡；這就導致了大部份那些我們觀察到了卻無法理解的各種奇妙又魔幻的一件件具體事例了！

最後我想要稍微岔開一下做個補充。也許我前面的說明會讓一些讀者感到或害怕或疑惑，因為雖然人類歷史上這種大動亂的時代並不少見，但好像也沒有到隨便動不動就要面臨毀滅的地步！其實人類的社會是一個渾沌的綜合體，內含了各種面向和各種不同的結構與模式，雖然整個大毀滅的事情並不是沒有過，但我們通常更常經驗到的應該是只有某個部份的秩序結構毀壞的情況。舉例來說，臺灣的交通就是出了名的各種亂七八糟不合理，而在此狀態下我們其實經歷過不少舊秩序失效，然後人民與人民、人民與警察之間重新建立起另一套「規矩」、「生態」的這個過程；但是整個社會並沒有瓦解而分崩離析，僅僅只是整個大社會下的某這麼一個生態秩序經歷混亂、毀滅、和重建而已。又或者可能像是一個社會哪哪看似都很合諧，但只要一涉及到婚戀、彩禮、誰出錢、誰煮飯這些事情，就會陷入你爭我奪的畫面。總之一個人類的大社會是可以分割成許多不同的面向的，而通常我們能在不同的面向上看到不同的合作與自私、合諧與爭鬥的狀態。因此我本文的這些論述雖然概念上比較宏觀，好像動不動就「社會崩壞」，但實際上這些敘述對應到現實生活觀察裡的話，多半要套用在整個社會結構的其中或大或小的一部份；雖然說整個社會的大亂大合也不是沒發生過，但頻率低多了，說不定許多人一輩子可能也沒機會經歷到！

處女情結

Sat, 03 May 2025 00:34:13 +0800

在感情相關的討論裡，時不時就會出現與處女情結有關的話題，並經常能看到正反兩派之間的口誅筆伐。我覺得可惜的是這些討論中，無論是男方立場還是女方立場，大多都聚焦在情緒和感覺上面，以及對於對方的控訴，卻極少見有人能夠從比較公道的角度給出個公評。其實我也沒法為這樣的事情給出個什麼能夠讓各方都信服的公評，只是對這個既有現象做出邏輯解釋，讓人知道發生了什麼事情？

每當談論到處女情結有關話題的時候，討論區大致會分成兩個陣營，一方是擁護處女情結的男方陣營、一方是反對處女情結的女方陣營 (實際上當然存在反對處女情結的男士、以及為處女情結辯護的女士，但是那些都是少數而已， 只要不是眼瞎的人應該都能夠輕易看出來這兩個立場群體根本就和兩個性別群體高度重合)。支持的一方可能會表達出對於處女情結見怪不怪、或者認同，或者在心智上未必認同或不認同但承認生理上對非處女的厭惡，甚至有些人對於自己內心竟然存在這種政治不正確思想卻又無法扭轉而感到自卑焦慮等。反對的一方則通常無法理解為什麼男人群中會存在這種奇怪的思想傾向？常見她們表現出對於存在這種情結的人的噁心、忿怒、抱怨與責怪，並抨擊這些人是「活在清朝時代早該作廢的」、不符合當代兩性「政確」價值觀的大男人主義者等等。這些看似割裂且無法調和、無法互相理解包容的兩個群體，為當代的性別戰爭又添加了一個能在茶餘飯後再戰一場的話題。

如同我開頭所說的，我只是覺得大部份的這種話題爭吵都可惜了，基於情緒和感覺的言談除了抒發情感壓力之外並沒有任何建設性的作用，因此本篇我想要儘量從理性客觀的角度來為此剖析一番。

處女情結是什麼感覺？

處女情結是一種什麼樣的感覺？總的來說就是男性在擇偶一事上面對於曾有過性經驗的女性感到排斥厭惡的心理狀態，或者是可能並沒有特別厭惡非處女的感覺，但在選擇時更加偏好沒有過性經驗的處女的傾向。

整理綜合網路上看到的處女情結相關討論、以及男性們對於自身情結的自我描述，大約可以整理出男性的處女情結會有的表現型式或心理狀態。有些人描述一看到自己的女伴，可能就會想起她之前和其他男人翻雲覆雨的畫面；有些人會覺得她已經被別人用過了，而產生覺得她「髒」或「不乾淨」等厭惡心理；也有些人沒有這麼多的想像空間，單純就只是知道對方曾與他人有過性關係之後，就不再具有足夠的吸引力。在這些自述裡面大多都是在男士在知道自己的女伴曾與他人發生過性關係後，心理出現排斥厭惡，並且通常都是難以形容、難以具體描述的一種感覺。說不出對方到底哪裡不一樣了，也無法具體描述到底是哪個部份使人感到排拒，完全就是在知曉對方發生過性關係這事的前、後，男人內心狀態所產生的難以言語的感覺。

除了上述「難以描述的莫名」排斥心理之外，有些男士能以比較具像的方式描述其排斥的現實邏輯。例如有些人會說就是心裡難以接受「有些人年輕時喜歡和毛頭小子玩，老了才想找個老實人求穩定；毛頭小子花幾百元就得了你的初夜和魚水之歡的享受，到我這裡卻要車、要房、要收入，還要我遺忘她的過去！」也有些人能描述出的是心裡的邏輯，比方說「和女伴在做那些事的時候不自覺會和她的前任比較，若沒能贏過前任則容易產生自卑感，就算贏過前任也會讓自己處處感到被比較的壓力！」

當然，以上說的那些性經驗都是與自己之外的他人進行的才算，至於如果對方是和自己有的經驗的話，就算進行過一萬次都不會觸發處女情結反應 (至於七年之癢問題那是另一個主題了)。另外一個關於處女情結的表現可能是很多女性並沒有意識到的：男性對於處女情結的心裡狀態不見得在交往的時候就會反應出來。的確有些男性在進入交往關係之時就會因為對方非處之身而有厭惡感，但許多男性可能在交往期間完全沒有處女情結(這裡排除有些可能是壓抑隱藏欺騙的案例，只看那些真的就是沒有的)，然而在將要走入長期穩定關係的關頭時(也就是婚姻)，處女情結卻在這個時候浮現出來，並讓男女雙方都感受到挫折。

另外處女情結也並不全然是表現在對於非處女的厭惡排斥現象。有些男人可能自身完全沒有對於非處女的排斥感覺，只不過當兩個其他條件差不多的女性擺在眼前時，這些男性也許更加偏好於選擇處女。這種雖然沒有排斥非處但卻更加青睞處女的現象，其實同樣也是處女情結的表現。

處女情結真的只在意那層膜嗎？

女人大多難以體會處女情結並感同身受，常可見許多女性對於男性的處女情結表現出不以為然的態度，非常疑惑且不理解的說道「男人們難道就這麼在意那層膜嗎？那層膜真的有那麼重要嗎？！」 (似乎在醫學上這東西正式學名應該叫作「陰道冠」，但語言乃約定俗成，我也比較習慣稱呼為處女膜， 因此本文仍舊以大眾比較習慣的名詞「處女膜」稱之。)

其實站在男性的角度，男性從來在意的就不是那一層膜的存在與否；男性們真正在意的其實是心理上的唯一獨占性！

對於遠古那種還在獵巫的時代，還在迷信而未有科學發展的時代就算了不談，我們只看現代和近現代的部份。一個守身如玉的女孩子，可是因為運動等意外導致處女膜破裂了，請問男人們會在意嗎？會因此而低看這位女孩，覺得心裡排斥噁心嗎？我想這題答「是」的男人那可能真的是稀有罕見。相反的，如果一個女子已經閱歷無數、經驗老到、甚至有些花名在外，然後去做了陰道冠重建手術修復了處女膜，並且執刀醫術精湛，無論是看起來還是用起來根本都和真正的處子之身一模一樣，那麼男人們接受嗎？會因為她的身體已經與真正的處女別無二致而看待她一樣嗎？那種對非處的排斥心理到底是有所消減、或是煙消雲散、或是更加深刻、還是全無影響呢？我想問題思考到這裡，答案應該已經非常明顯了！

其實男性對於處女或非處的偏好或厭惡，與那層膜的存在與否還真的沒有關係。男性對於女性處或非處的糾結其實是源自於更加深層的心理感受和認知，也就是傳統話語上說的女人「乾淨」與否，反而生理上的那個組織的存在與否幾乎起不到任何作用；就算其他人可以舉出一些個案表面上看起來是因為女生的這個生理因素導致被嫌棄，但其實絕大部份當中那也是因為這個生理因素指向了心理的感受認知而造成的。因此最終的根本決定因素仍然是心理認知，而非生理結構的存在與否所導致。另外一個情境可以從旁呼應這種說法的可靠性，比方一對男女交往的情況很不錯，兩人的感情和互動看起來完全沒有任何問題，但是有一天男生發現原來女友以前有和別人發生過性關係(可能是或不是前男友，但其實不重要)。這件事情彷彿啟動了男生腦內的某一個開關，開始對女友產生反感意識，可能還引發自身的糾結思慮，最後放到網路上發文被我們看到(至於具體的個案就不說了，反正網路上一查一大堆)。欸這就有趣了，人還是同樣那個人，在男生知曉她曾經有過的過往的一秒前、以及一秒後，她的長相、個性、處世為人、體貼、學識等等都是一模一樣的，可是男人卻可能就對女友產生了嫌棄之心。相反的，有些故事裡的女生其實曾經有過經驗，甚至可能不乏閱歷豐富的，但是非常小心謹慎，將過往一切切斷連結並且隱藏的很好，而丈夫自始至終待她如初戀，一點點嫌惡之心都沒有，直到有一天發現妻子的往事之前…… (至於那些一輩子沒發現的可能就是另一個發展方向了， 只不過能留下記錄讓我們一般人讀到的故事多半都是後來出毗漏的)。

這些大量發生的案例其實都在告訴我們一件事：男人的處女情結是在心理意識層面裡的東西，反而不一定是在於生理結構的部份，甚至於許多處男可能也不一定分辨得出來。因此那些過度糾結「那一層膜真的就那麼重要嗎？」的女人們，其實都搞錯了核心的問題所在！

為什麼會有處女情結？

處女情結乍看真是個奇妙的東西。女人們大多無法體會、感受、和同理男人的處女情結，更不乏有些人大放厥詞抨擊認為男性根本不應該有此情結；而男人們其實也不是刻意想要擁有處女情結，可能一大半也不知道自己為何就會對處女或非處產生莫名其妙的「感覺」，甚至有些人自己為此感到矛盾困擾！並且這東西好像是只有男人才有的，我們極少看見在女性身上出現這種莫名而來也揮之不去的處男情結。

可能和許多女性朋友所想的相反，處女情結並不是來自於教育或文化 (雖然它們可能會起到一點強化或抑制的作用)，否則在從出生開始就接受現代性別教育長大的這個世代、以及下個世代，就不可能還會再有處女情結存在。處女情結產生的原因更是與什麼傳統大男人沙文主義沒有關係。傳統男性文化包含了對處女和貞節的要求，但處女情結本身並不只存在歸屬於這個範疇。它是一種自然而然的、莫名而來的，就好像天然就存在於男性身體裡的一種自然感覺。而這也就是為什麼即便到了現代，明明在觀念教育上已不再強調、在社會思想風氣也早已開放自由、甚至社會開放程度早已對性事見怪不怪的情況下，處女情結依舊能夠憑空而來，在男性的身體裡自然出現的原因。

說了那麼多，那麼到底處女情結為何會深埋在男性的腦袋和身體裡呢？其實前面已經一路在鋪陳提點許多關鍵字了。莫名其妙的感覺、說不清道不明的感覺、不知由何而來就天然發生的厭惡和喜好傾向、不用教就能自己會的本能，這一切一切不知是否讓讀者回想起我曾經寫過的一篇「人體的美感」？沒錯，處女情結與演化有關，它與人對人體的自然美感喜好源自於同樣的因素，也就表現出了完全一樣的特性。就好比人類即便不用教，即便一個孩子打出生就在叢林裡被狼王養大，當他或她一天回到人類社群開始大量接觸同類之後，一樣能夠本能的喜歡上帥哥美女而厭惡那醜的；又好比人類天生會怕黑、怕高、怕尖銳物體一樣，因為那不怕的人比較容易死去而沒能繁衍下來。

那麼男人的處女情結為何而生呢？處女情結給男人帶來什麼樣的生存繁衍優勢呢？其實就是男人們千萬年來最恐懼最反感的其中一項事情：帶綠帽子！生過孩子的女人們都清楚，帶孩養娃是多麼辛苦、多麼犧牲的，而這對男人同樣也是如此。男性們為了供養撫育自己的女人和孩子，往往需要做出巨大的犧牲、冒險犯難，甚至可能丟失性命，從古至今皆如此。所以， 男人們無非就是希望拼盡老命犧牲一切供養長大的孩子，是自己的孩子，是延續自己基因的新生命，僅此而已； 那麼對於那些可能隱含讓你養別人娃娃的風險，自然就會本能的產生厭惡感！ 這就是處女情結的根本源頭，那是來自於天賦本能，腦袋無需意識理解，因為千萬年來的歷練已經被刻在 DNA 裡了。也許你會說難道就不存在那些沒有處女情結的男人嗎？有的，我相信這種無私大愛的男人確實存在過，只不過在億萬年的時間裡面大多都幫別人養孩子去了，不容易留下子嗣，基本已經沒法讓我們現代人遇到！

而這其實也解釋了另外一個問題：為什麼就幾乎沒聽說過什麼女性有處男情結呢？女性經常表現出不能夠理解認同男人處女情結的現象，是因為女人身體裡面本身就沒有這樣的機制，自然難以感同身受。 那麼女性為什麼沒有處男情結呢？因為女人無需要擔憂生的孩子是不是自己的孩子這個問題啊！ 但凡由自己身體生出來的孩子，難道還能不是自己的而是別人的嗎？ (什麼你說代孕？別開玩笑了！即便是在現代，代孕的情況也都是極其罕見的事情，更何況億萬年來的演化歷程。) 這也是老輩們口耳相傳的一句話：孩子不一定是不是女婿的，但肯定是女兒的！至於許多女性憤憤不平的說「憑什麼女人的貞節就這麼被看重，而卻沒有人在乎男人的貞節呢？憑什麼男人經驗豐富反而能讓其他人羨慕傳誦，女人卻被嫌棄掉價呢？」那麼這就是原因了，雖然可能讓人覺得不公平，然而演化的現實就是這麼運作的。

對於生出來的孩子不是自己的種，對於勞心勞力獻出一輩子的心血卻幫別人供養孩子，這是男人們心底深處恐懼和厭惡的源頭。其實這個源頭所產生出來的行為現象還有非常多，處女情結只不過是其中的一個項目而已，而若再深入探討更多男性在兩性關係中的行為表現，還會發現更多的行為傾向其實都來自於這同一個源頭，只不過那些其它的行為現象不是本次的焦點所在。無論如何，從身體而來本能性的迴避那可能會讓自己有帶綠帽機率的事情，能夠提高男人延續自己後代的機會，因此自然在漫長的演化經歷之中被保留下來，並且得到強化。在這樣宏大的敘事背景之中，處女情結反映出來的其實是女性的忠貞程度，也就是女性對於單一一個對象押寶並下好離手的堅定之心、以及對於其他誘惑的抵抗能力。這並不是一種百分百的保證，非處之女不見得在後半身就不能夠忠於一個丈夫，處女也不見得此生絕不會背叛；但是直到婚配之前仍能保守童貞之身的人，顯然就機率來說是更好的選擇，更加值得讓男人押寶抵上人生。 (當然男人腦子裡可能並沒有這麼複雜的利益比較，因為男人的身體會很自然的告訴腦子該喜歡哪個、討厭哪個)

這裡可能有些女人要聽不住而準備要跳腳了，請你們先別急。有些人會說處不處並不能保證肯定忠心啊，結婚時候是處女，後來出軌的案例也不少啊？的確，處女身並不是女人忠貞不二的肯定保證，但是以機率來說確實是提高了機率，因此在演化中因為有用而得到強化。因為處女身並不是女人忠貞不二的唯一保證，因此除了處女情結之外，男人們也同樣演化出了各種其它的喜好天性，比如說對於水性楊花個性的人、與他人互動沒有邊界感的人，男人也會本能性的迴避 (玩玩的情況不算，這裡只單指要走向長期穩定關係的選擇時)；對於長期穩定關係中的伴侶出軌時，男性的容忍度也普遍遠小於女性。其它還有更多行為與喜好族繁不及備載，但是它們共同加在一起，綜合起來成為男性們延續基因的觀察依據；並不是真的只靠一個處女情結就能夠打定所有事情，但是處女情結確實是這當中一個相當重要的一塊存在。

時代不同了，處女情結該不該繼續存在？

這節的標題是在與處女情結有關話題的時候，女性們經常會說出來的話。許多女性認為男性的處女情結是守舊的、迂腐的、男性沙文的、食古不化的、萬惡的等等，常能見女性說「清朝都早已經滅亡超過一百年了，怎麼還有男生抱有這種早就過時了的思想？！」然後把這一切罪惡歸咎於男人，「都是男人的錯，都是男人的陰謀！」但是事實上真的是這樣嗎？

既然處女情結並不是男性有意為之，而是本能的天性所致，那麼本節的問題其實就不應該是「該不該」繼續存在，而應該是「能不能」被抹消？其實答案已經顯而易見了，不能！因為這種經過億萬年千錘百鍊演化而來的天性早已深刻的刻入每個正常男性的骨髓裡，難以揮去。你沒有辦法用理性的邏輯去消抹那早已成為天性的本能反應，就好比以現代科技水準來說，嬰兒奶粉早已可以取代母乳餵哺幼兒長大，女性的泌乳能力早已與嬰孩能不能生存成長這件事脫勾；但男性會因此不看重女性的乳房嗎？在擇偶的傾向與偏好上，能夠完全忽略女性的胸型身材，並與平胸的女性一視同仁的同樣喜歡嗎？我想這麼現實的問題，但凡有經歷過任何情場的不論男女都能果斷的說：怎麼可能？！

其實現代大部份的兩性問題之間的不解疑問，都是源自於人的天性和社會理論現狀之間的矛盾衝突。什麼意思呢？既然女性大多不能夠感同身受體會男性在處女情結上的心境，那我來換個女性能夠體會的例子說明。在現代社會，至少在我們所生長的這個地方，女性早已大量在職場上工作，大部份普通情況下與男性沒有根本性的差異，表現比普同男性更加傑出優秀的女性更不在少數。就理論現實來說，如果一位女性的收入能力在一個月 15 萬左右的水準，那麼她完全可以依靠自身能力撐起並供養一個家庭，包括自己、丈夫、和孩子。理論上這樣一位女性可以完全不在乎配偶的收入水準，就算男生只領 3 萬月薪又何妨？甚至就算男生沒有收入又何妨？然而在實際的現實上，我們知道普遍這樣一位女性是很難能夠接受這樣的男性的。也許有些女性並沒有意識過這種不對等的現象，她們會覺得這有什麼好奇怪的？對比自己還弱、還窮的男性本來就很難喜歡，這不是很正常應該發生的事嗎？那麼我說，把性別掉換過來的話，在男性群體普遍並不會因為女生窮、弱、社會能力不優秀等原因而對她「沒感覺」。

因此即便理論上並不需要男性的收入能力，但是女性卻很難打從心底青睞而不嫌棄一個能力比她差這麼多的男性，即便在理論上兩人可以合力經營家庭，即便邏輯上並不會導致他們無法成家生子過生活。這就是天性，是億萬年來千錘百煉的演化結果在女性身上展現出來的天然喜好，是無需任何人教就會的傾向，是即便在兩性平權文化和教育為主流的思朝之下依然不能夠撼動的女性天性。你可以儘管在理性層面上去解釋、去遊說女性說嫌貧愛富是不對的，說 AA 才是公平對等的，說現代社會女人可以靠自己而無需依附一個強壯男人的力量等等，但依然無法讓女性去喜歡一個窮弱男人而不是富強的，也不能讓她不對強健素質的男人起心動念卻反而對瘦弱自卑的男人傾心。

這就是天性，演化的天性，基因的主導力。本文無意去進一步解釋那超出本篇主題的其它現象，提出上面的說明也僅只是試圖使用女性能夠理解體會的現象，來幫助理解男性為什麼會天性存在處女情結，以及幫助體會男性對於處女情結的無能為力而已。

那麼回答本節開頭的問題，在現代這個時代，處女情結能夠被消滅嗎？顯然是不可能的！這些已經深埋於男人與女人之間的天好傾向，至少在幾代人的有生之年內是不可能改變的。而任何嘗試與之怒吼對抗的人就如同用螳臂去阻擋人類社會的大車輪一樣，除了徒勞無功之外不會有別的結果！

男性如何調適處女情結？

經過前面解釋可以知道，但凡成熟的正常男性無不存在處女情結的，只不過差別在於發作與自知的程度而已。不過處女情結只不過是眾多擇偶天性裡面的其中一項而已，並不是不能夠妥協、交易、和取捨的，而這些過程其實就是本節所謂的「調適」過程。

這些調適準備可能是自我驅動的，也可能是經過周圍朋友家人等輔導接納的，最終的表現就是可以一定程度的放下處女情結，或者降低對處女的要求和期待。這些現象甚至可能大部份並不需要被搬到檯面上來處理，很多男性在自我心智的階段就自己內心調適掉了；還有一部份是在天性的自然權衡利弊之中就已經處理完畢，以致於可能有些男性自始至終從未意識過自己竟然有處女情結！其實像這樣的調適行為在很多其它的事情上也是存在的，而且也是符合演化邏輯，否則就以現代這個性開放風氣橫行的社會，如果還是保有這麼強烈且無可退讓的處女情結的話，那麼還有多少人能夠結婚生子呢？

說到底，處女情結是男性生存繁衍策略上一項很重要的風險管理能力，但也終究只是其中一項而已；男人們沒有人喜歡被帶綠帽(或者有機會被帶綠帽的感覺)，但是擺在生存繁衍這條路面前的風險困難還有很多，比如男生謀生能力、女生基因品質、年齡、社會階層等等。在顧全大局的最終指標之下，單一的一項堅持並不是不能夠妥協退讓和交換的。用更加白話的方式來說，其實就是當男性自身的擇偶選擇範圍比較狹窄的時候(也就是比較少女性能夠願意要他的時候)，處女情結可能就會自然的退讓消弭。

用一個極端但容易理解的例子來做說明，就拿躺在路邊要飯的那個乞丐來說，如果今天有一個女生過去和他相好，做他女朋友，甚至願意嫁給他，那你看這乞丐還在不在意這女的是不是處？甚至人家二婚三婚、八大行業又怎麼樣？還會嫌棄這女生嗎？當然作為旁觀者我們其實明白這不過就是沒得挑了所以顧不得那麼多其它的，可是以那個乞丐本位來說，他搞不好自始至終從未意識過「其實我是在意的，但我知道自己幾斤幾兩，所以選擇包容退讓和忍受」這件事，因為這些東西很可能在身體天性的運算之中只在 0.1 秒就計算完成並且做出決定，甚至於沒有機會進入到腦子的意識之中令他注意到這件事。 這就是我說的「在肉體天性的意識之中自然權衡處理掉」的情況，因此甚至連他本人可能都未察覺； 而在我們一般大眾的認知之中，會將這類人物歸類為「沒有處女情結」。 然而他是真的就沒有處女情結嗎？即便連他本人都沒有意識到處女情結的存在，但他真的就不存在處女情結嗎？答案是否定的，因為處女情結是天生產物，只不過是被壓抑住而已。假若有一天這乞丐不小心走了狗屎運飛黃騰達了，成了老闆、當了總裁了，你就看他那時候再挑女人時在不在意人家是不是處女？

經過極端案例的探討之後讓我們回來普通現實，我們就會察覺到一件事情： 男人們不可能不存在處女情結，而在一般女性認知中所謂的「沒有處女情結」的男性， 終其所以只不過是在擇偶選擇為數不多的情況下而自然做出的退讓而已！ 而許多男性能夠長期不爆發並且一直保持沒有處女情結的形象，更大的因素可能是一般普通男性終究是平凡人，終其一生沒有能夠飛黃騰達的機會罷了！

內心糾結的男性

大部份的普通男性都會在人生當中自我的調適對於處女情結的心理狀態，但也有一部份的人察覺到了，可是卻不能夠良好的自我調適，於是我們就會在網路上看到這些男性表達出心裡痛苦的情感抒發或者求助文章。

整理這些男性的故事都有幾個共通點。他們有些是真的沒有擇偶選擇空間，離了這個現在的女朋友的話還不知道能不能找到下一個；也有些人並非完全沒有選擇範圍，但可能一開始時並不知道女性的情史，或是過度自信的認為自己沒有處女情結，或是一開始以為這沒什麼大不了的，於是有一天發作起來的時候兩人的感情已經進入一定的深入狀態，因而感到痛苦拉扯。然而這些案例裡面就沒有一個是擇偶範圍非常寬廣的男性。對於這些大情聖似乎從來就不存在處女情結的糾結問題，而他們處理這些情況的一致方法通常是不帶眨眼的換人。

除了擇偶選擇面的寬窄程度之外，另外一項導致男性心裡糾結的因素應就是現代的兩性價值觀教育造成的了！撇除掉分了這個還不知道有沒有機會遇到下一個的這種情況之外，不論是一開始不知道而後來才發現女生的過往，或者對自己面對這種問題的心裡素質過高的期待，總之有一天內心的處女情結冒頭和發酵，止不住的心裡嫌棄厭惡身邊的女人。這時雖然男人內心壓抑不住對女伴的嫌惡感，理智上卻認知自己這樣的想法是不對的，是不正確的；相信自己不應該要有這種已經不合時宜的老式大男人沙文想法，卻又止不住內心對女伴的嫌惡感；認為自己應對兩人付出的感情承擔負責，卻又無法真正接納女伴。這種兩頭的心智拉扯便成為男孩內心中痛苦糾結的主要因素。

對於這樣身在痛苦中的男人，是對是錯我不給予意見，不過建議讀過我以下的類比舉例之後，讀者們再自己給這些事情做評判。

如果說要我用什麼方式來和女人形容這種男人內心的痛苦糾結情緒的話，那麼我們需要像「大雄的如果電話亭」那樣想像一個不符合當今社會狀態的環境。假如你交了一個男朋友，這男朋友沒錢也沒啥本事，還經常需要你贊助他生活費。你心裡其實蠻反感這男友，有個想法想要把他一腳踢開換別人，但是你卻清楚這麼做是不對的。因為在這個假想的時空環境之下，女人本來就該當家做主，男人吃軟飯本就是天經地義的事情，而且你的朋友、閨密們的男朋友很多也是這樣，姊姊、阿姨們的老公也大多都是要靠女人養的。雖然偶爾也會有一些人的老公具有相當的經濟實力，可以和老婆平分家庭開銷、出去吃飯可以 AA。這些少數案例雖然也讓姊妹們覺得很幸運，但是如果你因為這樣而嫌棄男友，甚或將他掃地出門的話，那你一定會被大家罵爆炸，什麼「滿清都已經亡國多少年了？」「你竟然有這麼大女人主義的齷齪想法！」「都什麼年代了，你不養他，難道還要他來養你嗎？」等等話語絕對會讓你社會性死亡，成為眾矢之的。並且你自己的理智上也同樣認為這麼做是不對的，因為從小生長的社會價值觀就是這麼教導你的。那麼如果真的身處這個想像中的情況，你會不會拉扯糾結？面對這個你明明已經沒感覺不喜歡或甚至有些厭惡的對象卻不能夠瀟灑走人，你會不會如同嘴巴吃了蒼蠅一般的感到噁心？好的，那麼，其實在現代社會因為處女情結而感到痛苦糾結的男性們，其實就是這麼回事！

無情的男性

對於處女情結的調適，除了會自我退讓的大部份普通男性、和調適不了而產生糾結情緒的男性之外，還有另外一群男性，他們的調適方式就是不調適，不合就換掉；通常他們會需要女人來調適自己以配合他們。

他們這種高高在上的樣子，豪不顧惜女人情感和歲月蹉跎的做法，通常讓女性們又恨在心裡又愛在眼裡。這就像是通常那些長相頂漂亮的女性容易養成任性自我性格一樣的原因，因為情感追求天平的不對等，使得存在空間容許漂亮美女發展此種性格。同樣的原因，能夠做出這種讓女人們罵在嘴裡的行為的男性通常擁有相當不錯的擇偶優勢條件。站在高地的他們並不擔心缺乏可擇偶的對象，甚至於可能還有許多女人巴不得要去攀附他們，因此才會形成前面所形容的這種又愛又恨的情況。此外，擇偶優勢條件加上情感歷練豐富，早已感情脫敏的他們在面對這些事情的時候往往可以更加果絕而無掛慮。與他們的薄情寡義相反的是，在他們瀟灑遠去的背後，留下哭的死去活來、或者暴跳如雷的女人！

白紙找白紙，報紙找報紙？

對於處女情結有關的話題，贊成或批評總是各有立場，但其中有一種說法特別有趣。有些女人提出一種想法，也許是意識到了男性不可能根本性消抹處女情結的原因吧，他們接受了有些男性擇偶時對潛在伴侶的處女身要求。不過這種合理並不是無條件的，這些女性提出的想法認為男性提出處女的擇偶要求是合理的，但前提條件是男性自己也得是無經驗的處男。就好比要求男性身高 180 的，女人自己應該至少也要有 170 的邏輯一樣；或者像是要求男性月收入要 10 萬以上時，女人自己的薪水也應該達到 8、9 萬以上的說法邏輯相同。總之就是每個人的要求都可以是合理的，前題是要對等公平。於是乎這麼一個說法便出現並廣為流傳：「就讓處男去挑處女、非處男就找非處女；白紙配白紙，報紙配報紙。」

這麼個說法看似公平、對等、合理、等價，一時之間似乎大家都找到了公約數，不論男性或女性、不論在處女情結一事上或讚或反，在這句話面前似乎大家找到了停止爭論的最大共識！然而這裡我卻要給大家潑一桶冷水。我說的不是理論正確的話語，卻是現實的描述；因為理想是美好的，但現實卻是殘酷的！

處找處、非處找非處，這麼一個公平正確的要求多麼美好啊？想找處女可以，但你自己也得是個處男，否則自己經驗豐富卻想找個乾淨的處女可不讓人感到噁心不恥嗎？！但是現實社會卻不是這麼運作的。 實際的情況往往是：處女最後嫁給了非處男，而處男最後娶了非處女，或者娶不到任何一個！ 是的，這才是現實。這句話可能會讓許多好不容易拾起自信心的女子們再次破防，然而現實就是這麼運作的，而我們口中那個合理公平誰也不虧歉的理想情況多半並不會發生！

這些事情乍看讓許多女性感到惱羞忿怒，然而稍加思索推敲就會知道這是極其合理且自然會發生的結果 (這裡我說的不是正不正確，而是合不合邏輯)。不妨思索一下，請問在現代我們所處的這個社會，男性為什麼會沒有性經驗？但凡是個正常的男性，誰不想要有性經驗呢？於是男性的性經驗有無，甚至於性經驗的豐富與否，其實並不只是表達男性的性經驗如此而已，它背後反應的其實是這個男性個體在女性間的受歡迎程度，也就是受女性所青睞吸引的程度。男性的性經驗往往與男性自身的條件優勢呈正相關。前面所述非處男最後往往娶了個處女，其實就是這些條件優渥的男人往往不會是處男，甚至會是經驗豐富的海王，而他們並不缺乏可以挑選的女性對象。在面對各種問題時，他們往往有得挑、有得選，他們更加有空間能夠遵循本心而無需過多遷就或退讓。因此在選擇長期伴侶的時候，他們往往更有底氣去篩選那些本心所青睞之人。你可以儘管說他們不合理、不要臉，儘管揶揄他們自己經歷豐富但娶太太還是要挑處女，儘管怒罵他們造成了許多非處女後卻還是要找個處女結婚，但是他們仍然這麼做，一點不受影響，並且他們有這個本事要挑且還找得到。這些男人們也不會因為你的狂怒飆罵而有所改變，更不會轉而來找你結婚。無論理論的公平講的多麼有道理，但現實又殘酷的世界就不是照那樣運作的！

至於處男呢？與前面所述相同，一個男人之所以會沒有性經驗，其實不過就是因為找不到女人罷了！找不到女人，不過就是因為自身條件(包含財富、地位、外貌、能力、性格等等綜合條件)實在不夠讓女性多看兩眼，以致於幾十年的時間連一次性愛的機會都得不到。當然我知道這裡一定很多人會跳出來反駁，說很多人是秉持婚後派的，還有因為宗教信仰的關係堅決婚前守貞的等等。對，這樣的人確實是存在；但請各位捫心自問，就在現在我們所處的這個社會環境，這樣的人(特別是男性)到底有多少？我們走入現實不自欺欺人，絕大部份的處男到底是因為為了守衛心中的信念而堅持，還是單純因為交不到女友而被迫守貞？因此這樣的男性最後往往是能夠有對象就不錯了，哪輪得到挑挑揀揀！甚至往往得接手那些「已經玩夠了，想安定下來」的女性，而這類女性基本不可能仍是處女。

於是最終形成了本節一開始所描述的現象，非處男性最後往往不會傾向選擇非處女，因為嫌棄人家不乾淨；處女往往不會嫁給處男，而是嫁給非處男，重點不在於處不處的，主要是非處男更加令人嚮往。而大量被非處男給淘汰出來的非處女，則不得不將就嫁給沒那麼霸道的非處男，甚至有些得找處男接盤。剩下還有許多處男，也就是「那些」女人們口中最「高貴」的物種，卻沒有人願意選擇嫁給他們，並且更加殘酷的是其實也沒有人在乎他們是死了還是活了！

女性為何激烈反對？

在有關處女情結的討論話題上幾乎總是能見到女性的大肆抨擊 (這類女性佔比多少我不知道，但是她們的網路聲量挺大是真)，比方常見會說出「現在還要找處女的話，可能只能去幼稚園裡找了！」或者「你們這些可悲的男人，竟然在意人家是不是處女？」「女生根本就覺得很噁心，也不會想找那種要挑處女的男人！」等等。話語中表現出極度的厭惡與反對，好似男性有處女情結本身就是一件錯誤的事情。她們不只不能理解處女情結，還覺得處女情結本身是有毒的、是錯誤的、是過時的古沙文思想，是令人反感的，且是任何男人膽敢存有這種想法就應該要被嚴厲批判的。她們鄙視並敵視那些表達出處女情結傾向的男性、或者支持這種情結的男性，並且帶有忿怒情緒的回擊這些男性。

但是不知道對於一個無利害關係的旁觀者來說，會不會對於這樣的現象感到疑惑？道不同不相為謀，你們不是一類人，也不會有交集，表達反對不認同是可以理解，但是情緒激動的攻擊這就很耐人尋味了！然而在這表面的情緒機動之下其實隱藏的卻是完全相反的事實真像。

就人性而論，如果你真的輕視、低看某類人，那麼正常來說你會迴避疏離他，而不是怒罵攻擊他；除非他損害到了你的利益！這就好比通常一般不會有人去對著路邊要飯乞丐氣急敗壞的叫囂說：「你們為什麼廢在這裡？為什麼不好好努力奮發上進？(這樣就可以娶我了！)」不，我們不會這樣做！因為你我他就不是一類人，彼此也無關係瓜葛；也許你會瞧不起這些人，但不至於氣血攻心的破口大罵。那麼為什麼這些女性對於那有處女情結的男性如此暴跳如雷呢？如果這些有處女情結的男人真的都是她們口中的老弱病殘低等物種的話，至於如此嗎？其實從前面一路讀下來的讀者大概已經可以猜到了，真像其實是這些存在處女情結的男性往往就是女性們最為嚮往的那一群男性；並且那愈讓女人傾心神慕的男性，往往就是處女情結最嚴重且不能退讓降低的男性！這些男性們往往並不排斥和你男女交往風花雪月一段時間，但是一旦開始要考慮穩定的長期關係(也就是婚姻)時，這些女人們往往在這個時候吃鱉；或者有些不那麼風流的一般共識下的好男人，可能發作的時間會更早，會在兩人穩定交往關係的前後時間就能感受到來自於男性伴侶的厭惡嫌棄情緒。這些其實才是為什麼讓女人們對此話題如此瘋狂激動的最重要因素！

至於有些人主張不合就換，建議女性不要去糾結和理會那些有處女情結的男性，只挑選那些沒有處女情結的男性發展關係就好了。可是真的照此原則嘗試的話卻可能很有機會發現更加令人感到挫折的真像，那些所謂沒有處女情結的男性往往是女性們要屈就自己才會願意去接納的對象。好不容易終於尋覓到一個條件還算滿意且沒有(還未發作)處女情結的好男人，結果隨著關係深入才發現其實他也是非常在意的，甚至可能一開始就是騙你的！這不斷的挫敗、氣餒、和焦慮，可能才是導致這類女性逐漸走向魔征的真正因素！

如果到這裡你還為這樣的說法有所疑惑的話，那麼可以試著觀察看看周圍能夠見聞的女性。看看那些對處女情結一事反應最為激烈的都是什麼樣的女性？她們的情史經歷如何？然後再看看那些無論任何原因而從未有過性經驗的女性，在她們之中反應激烈的又有多少？然後就能應證這件人性的根本邏輯：激烈的敵對現象源自於利益受損！

女性該如何應對處女情結？

解釋完有關處女情結的前因後果和各種面向之後，對於那些在處女情結有關的事情上遭遇挫折或焦慮的女性，我可以給出一些建議；不見得效果如何，但您可以參考看看！

首先女性們得放棄不切實際幻想，要認知到但凡是個正常男人就不可能沒有處女情結的！ 那些鼓吹「道不同不相為謀，挑沒有處女情結的男人就好」的說法，很大成份(其實還是有些許正確性，下面段落就會提到)不過是自我安慰的說辭而已。一旦你打定心眼只篩選並挑選那看上去沒有處女情結的男性，那就會和有些年幼小女生嚷嚷著想要找個不色不黃的男性一樣可笑。因為到頭來會發現你只會找到騙子，要不然就是性取向不正常的，再不然就是矮矬窮了！因此放棄幻想，正視現實，可以讓你更加務實的分析彼此的籌碼份量，至少在失敗的時候不至於那麼受傷無法忍受了！

接受現實之後，就要降低對擇偶的要求和期待。如同這整篇文我所解釋的，女人要認知到失去了處女身確實是一項求偶市場的減分項，特別對於那些愈容易讓你嚮往傾慕的對象可能減分愈多！那麼除了用自己去試試頭破血流的感覺並蹉跎青春之外，對自己有個清楚的認知並適當的放低要求、接納那些綜合條件比較沒有那麼亮眼的男性，可能會是更加務實的做法。所以那些流傳「略過處女情結男，只挑沒有處女情結的男人就好」的說法其實也不是完全沒有邏輯，這話背後的本質其實就是拐個彎要女人放低標準、降低對男性條件的期待。因為我們知道那些所謂「看上去好似沒有」處女情結的男性，其實不過就是權衡利弊之後(可能是潛意識層面就做完的)的退讓取捨而已。因此所謂挑沒有情結的對象，其實就約等同於找個沒那麼亮眼的普通男人！

失去了處女之身的女人就一定沒法找到好的男人了嗎？這答案也是確切否定的！也許面對那些頂規的男人們大概是真的可以不用妄想了，但是對於一般範圍的優秀好男人其實也並不是沒有機會！就如同我本篇所解釋的， 處女情結確實是男人天生相當在意的一件事，但其實也只是眾多在意的條件當中的一項。 觀察現實也是同樣如此，即便有過性經驗的女性確實是一項求偶不利的因素，但在現代社會性開放風潮之下，也不乏大把這樣的女人找到不錯的歸宿，組成幸福溫馨家庭者亦是一抓一大把。然其本質其實就是用其它更加優秀的條件來置換消弭這些不利因素。因此，女性其實可以從其它方面來補償自身包含非處之身在內的許多劣勢，比方說溫柔體貼、懂人情世故、排憂解難、互相扶持，或者擁有過人的膽識與智慧，或是足夠美艷動人其實也是可以！

此外女人們也需要具備足夠的成熟懂事，切忌在本文所論及的主題有關的事情上去提醒和刺激自己的伴侶。如同我前面所解釋的，男性對於處女情結的自我消化，在本質上是一種多方競爭條件下的的退讓置換和妥協，並且這樣的一個權衡利弊的過程不一定是在有意識的情況下進行的，甚可能許多男性大半輩子都沒有在腦子裡意識到這件事。那麼如果一個女性不懂得把持，還喜歡作妖去戳人的敏感的話，那麼也許有一天她的伴侶突然就覺醒意識，權衡一下(心智或身體)之後發現自己虧大了，那豈不是女人自己把自己的幸福給作沒了？就算也許不至於拆偶散伙，但兩人之間存在的隔閡和不平衡的情緒，要再繼續相親相愛後半輩子，大概困難阻礙少不了了！

所以你會發現，這一招之所以能夠有所作用，甚至能幸運找到比自己實際應該能夠匹配的好得多的對象，很大一部份其實源自於訊息的不對稱。因此這些方式多半也只能夠被用在那些一般範圍內相當優秀的男性而已。至於如果想要靠這幾招去挑戰頂規男性？開玩笑！那些各各都是人精，而你竟然想在他們面前耍大刀求拿下？對比現實也同樣符合描述，看那些叫得出名字的大人物，他本人以及包括他的孩子，有幾個人的配偶不是「乾淨」的女人呢？

對於有過性經驗的女性想要找個好人家安定下來的需求，還有一個說了會被罵死但卻非常有效、且自古以來經常被使用的方法：隱瞞、欺騙！ 如同我本篇所解釋的，其實你的身體是否曾被別的男人使用過，並不是開啟男人嫌惡的開關，而是那腦子裡的認知認定才是！那麼你幹嘛老老實實告訴男生你的過往事蹟呢？ (是的，這說法不符合社會價值觀，你甚至可以說不道德； 但是我不喜歡打高空，我講事實與現實，而現實是這真的有效用！) 管你是不是曾經身經百戰，只要男人不知道，就可以依然待你如初戀。這大概就是那些風塵女子決定上岸之後，為什麼總喜歡抹除過去一切蛛絲馬跡，並斬斷所有舊連繫的原因了吧！所以女人你真的可以隱瞞你過往的故事以換得一個對你深深相愛的老實好人家，唯切記一定要隱藏的夠徹底，且將過去斬斷的夠狠心，並且這會是你永遠不能說的秘密，直到與你一起進入棺材。至於如果你之前玩的太放肆，花名在外洗不掉，或者已經給你的身體造成無法隱藏的變化，或者總是能夠遇到可能將你的秘密給曝光的威脅的話，那就救不了你了！誰要你之前玩這麼兇呢？

另外，隱瞞過往這招式能夠有用處其實還非常依賴於一項重要的條件，那就是請找個沒有情感經歷的老實男，並且他們的綜合條件基本不會是太受一般女性待見的人物， 也就是坊間所說的「接盤俠」。 (我知道這裡老實男人要跳腳了，「老實人犯了什麼錯要招此對待？」 我明白，但現在我是站在女性的立場提出有效果的方案， 即便這方案不道德正確，但卻真的有作用；即便受傷的是老實男，但世界就是這麼運行的。) 因為這項手段能夠不破功的關鍵因素就是隱藏，然而對於那些受歡迎且經驗豐富的、許多女性都同樣喜歡的那種男性來說，這種做法沒有半點用處！因為就算你不說、就算你死不承認，可是你身體的許多反應，甚至你的人格特質和面對各種事物的反應，隨時都會透露你的底牌來背叛你，而你終究只有成為人家過水玩物的機會而已。因此這毒招式其實終究只能夠用來做降維打擊，只能應用在那些情感經歷單純，經驗缺乏的男性身上，最好是半輩子都在自己的世界裡耗費大量心力鑽研某種專業領域的男性了，單純好騙！我想也許這就是某地工程師之所以經常被大家調侃是回收業者的原因吧？！

還有一個問題有時候會被女性提出來問，那就是有必要去做手術修復處女膜(陰道冠修復手術)嗎？我的看法是在大部份情況下其實沒有必要！處女膜修復的作用在於可以欺騙發生性關係的對象，使他相信自己是第一個與你發生性關係的對象。但是對於那些經驗閱歷豐富的男性來說，這一點小套路完全無法掩蓋事實，因為他們可以輕易從你各種情況下的各種細節發覺端倪，因此其實完全沒有必要如此自討苦吃白作工，還不如一開始就開大門走大路；而對於那些缺乏情感經歷的純情小白，搞不好在做那事的時候根本也無法察覺有什麼不一樣？至於初夜沒落紅這事要搪塞過去也不是多困難的事情，反正現代的教育早就告訴我們不能以處女膜的存在與否去判斷女人的貞節，騎馬騎車和其它激烈運動導致破裂也是非常正常合理的情況。最終，只有對那些具有較為強烈的處女情結，並且同時符合了缺乏情感經歷且憨厚呆萌條件的男人，這個修復手術才能夠發揮點作用。

最後一招，其實也是效果最好且最有用處的一招，那就是守貞！ 是的，經過前面的反覆解釋，理應可以了解不論怎麼裝、怎麼演、怎麼補償，假的終究是不比真的更好！貨真價實的終究是比掩藏找補的更加可貴，也更加值得得到疼愛！所以其實女人守護自己的貞節而不給出(注意不是「不隨意」給出身體，而是不到婚姻關係建立為止絕不給出)，才是真正從源頭解決面對男性處女情結的唯一最優解法！是的，我這裡也是鼓勵女孩子守貞；但是請別搞錯了，我不是什麼衛道人士或宗教領袖，叫你守貞不是因為什麼所謂古板過時的沙文思想什麼的，也不是基於宗教信仰的立場，而純粹就是站在現實主義，以女性為主體的利益最大化邏輯下的務實選擇而已。一旦失去了這個「未開封使用過」的標籤，犧牲的是你自己的擇偶選擇範圍空間，特別是對於那些你可能會更有機會更加傾心愛慕的那些可能對象而言。是的，我大概又知道你要說什麼。我也同意處子之身只不過是眾多條件裡面的一項，也確實一個除了是個處女之外哪哪都不如人的女人同樣無法匹配到一個客觀滿意的那種優秀男性；但是這個身份對於那愈往高品質區塊靠近的男性而言愈是一種入門門票，一旦失去了，幾乎就等同斷絕了往那個方向攻略的可能性了！

檢討反思

處女情結有關的話題三不五時就會被搬上檯面互相撕逼一番。但琢磨下去不難發現這件事情其實不能夠歸咎於男性，因為這種已經化為天性的特性若沒有個幾萬年大概是無法撼動的了！而溯本追源也不難發現，現代這麼多在處女情結上爭吵的表像根源，其實就是近代性觀念開放且氾濫後所產生的自然結果。

那麼問題在哪裡呢？我認為在於文化和價值觀的教育，並且近代許多與性別有關的問題都源自於此！近幾十年來我們、以及歐美等先進國家所傳播的女性權益和性自主等思想價值觀的不夠完善，是導致這些問題的最大根本來源。但是請等等，別搞錯誤會我了！我並不反對這些強調自我意識和平等包容的價值觀，事實上我可太讚同了，我本人更是性別對等包容尊重思想的擁護者；而我所謂的禍源，其實是指向這些帶來改變的思潮不夠完善的那部份。怎麼說呢？現代先進的價值觀告訴女孩兒們身體是自己的、性也是自己的，自己擁有對自己身體完全的意志主導權。這說法太對了！我可太讚同了；但是，我們可曾教導過這些女孩子們與自由隨之而來的責任、風險、和代價？當小女生們在「我想怎樣就怎樣，誰來管我誰就是古板八股傳統守舊噁心又不尊重女性」而自由享樂的時候，可曾想過有一天可能會因此在戀愛道路上吃鱉受挫？在她當初做出那件事的時候，可曾準備好承受在今天要承擔的後果？這些，其實才是我真正想要點出的重點！

這又比如是一個具有獨立人格自由的少年選擇中斷學業而不是繼續升學，我想無論旁人怎麼看待，但是我們應該尊重他自己的思慮和選擇；無論未來的他會成為如賈伯士那樣的成功創業者，或者成為一事無成的落魄大漢，又或者接管祖產成為一個雖沒文化修養但優渥富裕的包租公，這些都是他自己要為自己承擔和冒險的。而我們唯一需要在意的其實只有一點，那就是在他做出這些選擇的時候是否清楚了解自己在做什麼？是否充份了解不同選擇所可能會給他帶來的不同後果，並準備好承受這些風險？如果理解了這個舉例說明，那麼再對照回來，就會發現我們當代的性別思想和教育所存在的巨大陷阱： 我們在教導性別相關的自我意識和自由主導權的時候，並沒有揭露其同時會帶來的劣勢和風險； 在教育孩子們理論上正確公平的價值觀的時候，並沒有告訴他們現實的世界其實是如何運作的。 使得他們在依照所信仰的價值觀而生活行事的時候，其實並未充份理解認知對自己的人生可能產生什麼不可逆的影響！

這就是我對這整件事的思考結論，也是想要諄諄教誨還尚年幼的年輕女孩們的核心思想 (至於那些已經失去貞節的反正已經來不及了，請回去參考女性該如何應對的那部份內容)。無論你想要如何使用自己的身體，是圖個即時享樂也好，是一時腦熱覺得當下這個人值得付出也罷，我並不反對你們的自由意志，也不代替你們自己去評價你們是對還是錯。我不是衛道人士，也不是宗教領袖，更不是你們的父母。我不代替你們去判斷做這些事情對不對、好不好、該不該；只是希望你們在做這些決定的時候，在事情還不至於無法反悔的時候，希望你能多思考：想清楚了沒有？準備好了沒有？決定以後不會後悔了沒有？

這時代的 C 語言還有什麼用處呢？

Mon, 07 Apr 2025 00:11:12 +0800

「在現在這個時代，學習 C 語言還有什麼用處呢？」這是現在從許多年輕學子身上能夠聽到的疑問，當然這問題也同樣能套用到 C++ 語言上。這裡我就以個人從業多年的學習與理解，分享我對此問題的解讀，告訴你 C (以及順便一提 C++)到底還有什麼樣的核心價值？

其實會比較深刻產生如標題這樣問題的應該大多是正在學習 C 語言的新手，可能是大學理工科的學生，可能是國高中第一次接觸程式語言的學生。埋首圍繞在程式語法結構的規則，正在學習如何用程式語言列印九九乘法表這樣的基礎練習中，翻看課本講義直到整篇結束大概都是這些東西，實在很難理解看起來就這樣能耐的東西，如何能夠演變成自己電腦上那個畫面炫麗的遊戲軟體？不過這個問題並不是我本次關注的重點。除了學生之外大概還有另外一群人，他們已經對程式語言具有一定的熟悉度和使用熟練度，至少已經脫離了學習痛苦期的深淵，已經能夠使用 C/C++ 獨立完成作業、小品，或基於某項具體功能的軟體程式製做。這些人對於程式語言的理解熟悉使他們的問題進入了另一個層次，也許不再懷疑這種基礎語法裡面只有看上去好像很簡單的一些功能的語言如何能夠製做出一個具體能用的程式。但是轉頭再看看其它更加現代先進的程式語言如 Java、Python 等後起之秀，它們使用起來可更加簡單方便且功能更加強大豐富得多，相比之下 C 語言(以及 C++)雖然也不是辦不到這些事，但是明顯感覺並沒有優勢。而這個問題就是本篇所要探討的主要議題，也就是 C 語言在現代被大量後起之秀環伺包圍的環境下，究竟還有什麼價值？在什麼用途上它能夠比其它的程式語言更加具有優勢嗎？

最後再提醒一點，這裡我探討的重點是 C 語言本身的價值和優勢，至於應不應該、適不適合作為新手入門的第一個語言……，那是另一個問題了！另外我在後面也要順帶探討一點對於 C++ 的評判。雖然嚴格意義上來說 C++ 與 C 是兩種獨立的程式語言，但是由於一些奇妙的因素使它們之間常常糾纏在一起，通常熟悉其中一個的人往往也很難得不熟悉另一個，甚至不乏有些程序員不能夠意識區分這兩者。因為它倆的相依相生，並且也正好我對它們都有一定的熟練度，藉此機會就一起分析探討一番了。

C 語言的價值與優勢

單純、精簡、輕便、高效

C 語言大概是現存的所有(高階)程式語言裡面最單純、最簡單的了。不過注意啊，這裡說的是語言本身語法、結構和邏輯簡單單純，不是說你學起來很簡單啊！這就好像是同樣雕刻一個大理石雕像，一個雕刻師拿了 CNC 車床外加五軸連動機械手臂、和五十個不同的切刀頭來進行工作，另一個老師傅卻只拿了一組六支雕刻刀加一把鎚子就完成了工作。這組雕刻刀簡單是真簡單，單純是真單純，能完工是真能完工，但不表示你學起它來也是如此簡單。這就是我說 C 語言簡單的真意。

C 語言的設計非常精簡精煉(當然這是指對於機器設備，而不是對於使用它的人)，並減少所有一切不必要的行為與工作，只以忠實完成程式設計師所明確交辦的工作為主，至於多餘的則當作不存在。這樣的語言哲學賦與 C 語言擁有與底層設備溝通並進行控制的能力，因此那些驅動程式、作業系統核心、以及硬體設備上的機載程式等等，往往必須由 C 語言來進行開發。加上它工作單純並且不自作聰明執行額外工作的特點，是 C 語言成為高效率語言的基礎要素，而這些特性卻是其它類型高階語言所難以俱備並與之比擬的獨特優勢。因此那些非常講究效能的用途如大量資料的快速運算處理，或者運算資源匱乏的用途如嵌入式設備程式等，或者需要在系統底層運作、或與硬體溝通交互的驅動程式、底層模組與程式庫等，就都喜歡以 C 語言作為主要的開發語言。

這裡可能有些人會不服氣，因為要比底層細部控制的話，組合語言(assembly)可比 C 語言更加瑣碎細緻並且接近硬體。話是這麼說沒錯，不過組合語言已經脫離了高階語言的範疇，不屬於高階語言了。因此這裡還得補充一個註腳： C 語言是在高階語言的範圍裡面最接近硬體邏輯與控制能力的語言， C 語言是最低階的高階語言！

當然好與壞是相伴的，否則 C 語言的這些特性這麼優良的話，又為什麼讓更新穎的當代語言紛紛拋棄許多比它們更古老的前輩所擁有的能力呢？ C 語言貼近硬體、貼近計算機底層，於是讓光是一個整數就有各種長度不一、區分有號無號的類型，可能還得區分堆疊空間、堆棧空間、還是全域空間，能夠充份發揮硬體最優配置是真，但是能讓使用者昏頭踩坑也是真。讓使用者直接操作記憶體地址賦與了完整的記憶體資料存取控制能力，卻也成為地址違規存取和堆疊洩漏發生的溫床；能讓使用者自由的索取與歸還記憶體資源，使程式可以在設計者的規劃之下最妥善高效的操作大量資料，卻也成為記憶體洩漏的最直接來源。使用者若沒有要求則不會對任何空間進行初始化行為，成為它效率高的其中一項因素，卻也導致各種未初始化引用的神奇問題，特別經常容易讓初學者摸不著頭腦。如果要細細講解的話其實還有很多可以提，但是這一切其實都在告訴我們一件事， C 語言的優點其實往往是背負著相對應的代價而來的。這些便是那些比它更加新生的語言之所以沒有想要「擁有」這些優點的原因，當然同樣也就是 C 語言在適當的使用情境下之所以比其它語言更加優異的原因。

教育與學習

C 語言還特別適合作為學習用途的程式語言，但請注意我這裡說的教育是有針對性的，而不一定是指廣泛情況下的教育用途。 C 語言的語法本身非常簡單單純，這點前面已經說過了，如果暫且不管熟練精湛程度而只看僅僅能「會」的話，雕刻刀顯然是比五軸連動 CNC 車床更加容易入門學會的東西，可能也因此成為過往許多學校教授學生入門程式語言的選擇。

C 語言的瑣碎、不多事這項特點在有些地方是缺點，但在學習階段卻反而具有強迫學生養成相對良好習慣的動力。至少要了記憶體得記得還回去，並且變數不設初始值、以及各種違規操作等，都很有機會在學習的階段就先爆發出來，想要不重視也不容易。需要使用者對各種東西進行細微的操作這點，更比其它語言更能夠讓學生在學習的階段一起感受體會到計算機的底層邏輯和運作原理，如理解記憶體與位址、堆疊空間、地址對齊、和呼叫與執行流程等等。

不過很明顯以上這些所謂優點是對於計算機相關科系學生的情況來說的，如果學習程式語言的目的有意要鑽研了解計算機相關知識並累積基礎的話，那麼 C 語言更是無法逃避的一個知識領域，必須得學，最好從一開始就學。至於非計算機相關科系，也不打算往這個方向發展，學習程式語言只是為了執行一些簡單工作的目的，或者作為興趣啟蒙的話，那麼這就是另一個話題了； C 語言不一定適合作為廣泛情況下給人的第一個學習入門語言，甚至它的瑣碎枯燥可能還會起到反效果！

作為軟體協作介面

C 語言在現代其實還有一個可能比較少人注意到但卻非常重要的價值，那就是作為軟體模組與模組之間的協作介面。

這是什麼意思呢？軟體程式往往都是被設計成許多不同的區塊來共同協同工作的，就好像是公司的不同部門、機關的不同處室單位、園區的不同廠房等。不同的部門即軟體模組各自專心負責自己的工作與任務，然後用某種連繫方式將這些部門給連繫起來，共同構成一個系統的一整體，於是乎，顯然就需要一種能夠讓各模塊共同使用的溝通交流介面。關於這個問題，其實幾乎所有的程式語言都提供了這種機制，然而這些機制大多都僅限於在使用同一種程式語言(甚至還得是同一個版本的編譯器)所寫成的模組之間。那麼問題就來了，現代其實存在非常多種不同的程式語言，彼此各有擅長和不擅長的地方，理想上最佳的做法是使用最恰當的語言去實現最適合的軟體模組，然後再把它們給連繫起來；但是，這些由完全不同的程式語言所製做的模組該怎麼樣統一交換資料並協同工作呢？這時候，C 語言就是那個最為適合的語言了！

有賴於 C 語言本身的簡潔單純並且缺少隱晦隱藏的各種奇妙機制，本來在現代各種先進語言面前應該是某種缺點，然而這些缺點卻陰差陽錯的在這個時代成為所有程式語言之間的最小滿足標準，成為用來定義軟體介面與界定彼此邊界的規格定義最佳語言，成為讓不同程式語言之間可以互相協同工作的中介者。對於那些學過不只一種程式語言的程式人，可以試著回想看看，是不是幾乎所有的程式語言都可以有辦法呼叫那些由 C 語言所實現的程式庫？對於大部份偏向系統面的程式語言(至於偏向使用者應用端的可能就沒有了)，甚至還能提供某些方式讓你製做出符合 C 語言規格的程式庫介面，讓其它由 C 語言寫成的應用可以呼叫你的程式庫(當然也包含那些能夠呼叫 C 語言程式庫的其它語言)；至於脫離了 C 語言之外，好像能夠提供不同語言直接互相溝通呼叫的介面就付之闕如了？！

這就是 C 語言在當代，除了用來實現底層驅動、以及極度講求高效能和低消耗的領域之外，可能更加關鍵重要的角色地位了，那就是作為千萬種各有所長的程式語言之間的溝通橋樑。學習和了解 C 語言的更大用處可能不是在許多人不知道一輩子有沒有機會接觸的系統軟體開發，而是在適當的時機可以讓你真正放開單一語言的束縛，可以放手使用最擅長的語言做它最擅長的事，並且還能將它們給凝聚協調起來。

C++ 的價值與地位

說了 C，就免不了也要提一下 C++。說實在的，在這個時代，與 C 語言仍然掌握核心價值不同，C++ 的位置算是有些尷尬！

嚴格說起來，C 與 C++ 完全就是兩個不同的程式語言，理論上應該是完全獨立的，然而實際上這兩個語言之間又存在著千絲萬縷的連繫，往往斷不了彼此的牽掛。 C++ 在誕生之初就將自己定位為 C 語言的超級擴充，號稱為一個「更好的 C」、「更加功能豐富的 C」。除了發明 C++ 自己的語法功能之外還延伸包容支援所有的 C 語法功能，並且在往後數十年各自的規格更新之中，二者也往往兼容彼此的新規格，因此使得 C 與 C++ 成為形影不離的兄弟。

然而理想很美好，現實卻不照著想法走。理想中 C++ 包含了 C 的一切功能，並且給的更多，然而這並沒有讓 C++ 完全吃掉 C 語言的領地，事實上 C++ 最大的缺點大多源自於它一開始所強調的優勢與豐富。

複雜、難學、不一定可靠

C++ 太過複雜龐大，是目前為止世界上公認最複雜的程式語言。有一句網路笑話是這麼說的：「那些說自己精通 C 語言的人有可能真的很精通；但那些說自己精通 C++ 語言的人，肯定不精通！」這句網路笑話就非常生動的表現了 C++ 的複雜，事實上往往愈是學習熟悉 C++ 的人，往往愈學愈不敢說自己精通(作者我自己也是愈學愈不敢)。

C++ 過於龐大複雜，首當其衝的就是對生手的學習和上手難度極大；但這其實只是最不重要的一個缺點，畢竟只要有價值，世界上學習難度更大更困難更複雜的事情也不乏有人前仆後繼去學習。它的過度複雜，使得語言的行為有時候很難弄得清楚；或者就算有人能夠弄清楚，還有些部份很難定義清楚；或者就算能夠定義，也很難保證編譯器的實現在這麼複雜晦瑟的規格之下能夠完全沒有意料之外的錯誤！這一切使得它的可靠性受到些許質疑，特別是在那些極度強調可靠性的應用領域裡更顯得令人不安！

環境資源要求

撇除這些問題之外，C++ 往往也攻佔不了那些原本由 C 語言所佔領的領域，雖然 C++ 完全相容 C 並且還給的更多，然而 C++ 的龐大直接使得它的運行時庫硬生生比 C 時庫膨脹近四倍(以 GCC 為例)，偏偏那些原本 C 語言所生存的領地大多都是運算資源與儲存資源拮据的環境！此外 C++ 的許多基礎功能其實脫不開一個完善的系統服務在背後撐腰，比如說例外機制、RTTI 等，而在 C 語言所生存的地方卻往往是需要實現並提供這些功能給別人使用的角色，而不是享受已經完善的這些功能。此等尷尬的局面使得 C++ 沒能夠吃下那些屬於 C 語言的領土。

當然我們可以選擇停用或刪除某些 C++ 的功能特性(當然前題是編譯器要能夠支援這麼玩)，以免除前述的一些 C++ 過於肥胖臃腫的問題，而我自己在將 C++ 使用到案子裡的時候往往就是這麼做的。但是這就很有趣了，這表示 C++ 的問題有時候並不是給的不夠，而是給的太多！並且更加弔詭的問題是，如果將 C++ 的功能過度現縮之後，使用 C++ 的意義也同樣在喪失！舉個例子，我看過許多產業介實際的程式碼，用的是 C++ 編譯器、副檔名是 .cpp，但裡面寫的全是 C 碼，那麼這還能夠算得上是 C++ 程式嗎？

上層領域對手眾多

前面說的那些都是討論在「C 語言所實際佔領並保有優勢的地盤」下的缺點，那如果在不是那麼令人膽顫心驚且斤斤計較的應用領域上，是不是 C++ 的豐富功能就能夠大放異彩了呢？這答案既是，也不是。確實 C++ 最為活躍擅長並能騰雲駕霧的地方不是和 C 去拼底層，而是在偏向應用層的領域裡去高效的處理各種複雜的工作。然而這就要說到本篇所強調的重點：「現代」。現代各種新興程式語言輩出，如 Java、C#、Python、Swift、Lua 等等等等，各式新生語言興盛且包圍環伺，它們比 C++ 更加簡單、方便，甚至在不考慮系統資源負載的情況下還能比 C++ 更加強大。這樣的局面使得 C++ 比上不足，只能在同時滿足了功能邏輯複雜或資料龐大、且講究效能、且系統資源不至於過度拮据的應用需求下，得到一些被需要的生存空間。

綜合平均表現最優異

說了這麼多 C++ 的缺點，那麼 C++ 就真的是一無是處了嗎？當然這也不對！ C++ 當然也是有點用處的，不然我自己還用著呢？！

雖然 C++ 的任何一項特點都有比它更加優秀的語言存在，但是 C++ 其實最特別的優點就是各方特性的平均評分總和最高！

論開發速度與難度，比不上 Python 等新秀，但它們在處理複雜演算法和大量資料時候的性能顯然沒有 C++ 優秀；論效能比不上 C 語言的高效精減，但 C++ 的開發效率與容易度可贏過太多，並且功能更加豐富強大；雖然 C++ 對於 C 等經常與底層打交道的語言來說往往過於臃腫肥大而難以勝任最接近機器的工作條件，但是在現代檯面上各種高大上語言唱主角的情況下， C++ 卻往往身居它們的底層，作為高效苦力支持者的角色存在，竟然成為了它們的基層功能和服務的供應者。此外前面那些「其它語言」的各種優勢往往是在依賴「讓各語言可以發揮自己的優勢在擅長的地方」之下的結果，在現實上為了能使之成立，除了需要有一個可以將它們綁定連繫起來的條件之外，當然也少不了團隊裡面需要有分別精通這些語言的各別專業開發人員。而如果你只有自己一個人、並且在一段時間內只能夠負擔學習並使用一種程式語言的話，那麼 C++ 就會是一個最為適合廣泛需求的語言；換句話說，如果一個產品因故必須只能使用一種程式語言來實現的話，那麼 C++ 在絕大多數應用場景裡可能就會是一個綜合評效最佳的程式語言！ 這也是為什麼當代許多份量大的程式如遊戲引擎等，仍是以 C++ 作為主力開發語言的主要原因之一！

活塞引擎 14：啟動

Sun, 30 Mar 2025 01:24:35 +0800

有關活塞引擎的系列差不多要告一段落了。當然活塞引擎主題還能有非常多的內容，不過因為我所知有限的緣故，不能再分享更多。那麼作為主題的最後一個內容，我們來看看一個可能有點意思的東西：如何發動一臺汽油活塞發動機。

怠速

在探討如何啟動之前，先來思考另一個問題：一臺活塞發動運轉的最低限度為何？也就是說，以最低的資源消耗 — 也就是燃料 — 維持引擎依然能夠自力持續運轉的最低臨界轉速。一旦發動機轉速低於這個臨界值，則將無法再繼續維持持續的運轉，俗稱熄火；另一方面這也是我們試圖從靜止狀態啟動一臺發動機的時候，所必須超越的最低轉速。

先看特性最為鮮明的單缸發動機。四行程活塞引擎在轉動兩圈的過程中只有其中的半圈能夠出力，而剩下的一圈半則不只不能出力，還得吃力才能夠完成，這部份依賴的是飛輪所儲存的角動能 ^[1]。飛輪的角動能大小與轉速的快慢直接相關，因此當轉速慢到某一個程度以下，飛輪就將無法再繼續提供足夠的動力讓活塞能夠順利的度過一圈半的行程。飛輪必須具有足夠的轉速才能夠供應活塞完整走過四個行程的循環，這項原因也成為在單缸引擎上決定最低轉速限度的主要因素。

當汽缸數量多起來，比方說當有了兩個汽缸的時候，因為兩個汽缸可以在不同的時間點發力，因此需要依賴飛輪動能的部份從單缸時的一圈半，變成只需要一圈就好。在飛輪的負擔變輕之下，雙缸配置下維持運轉的極限最低轉速自然就比單缸情況更低了。以此類推，三缸的最低臨界轉速又會在更低，而當汽缸數量大於四缸以後，轉速便不再受此限制。因為在四缸以上的情況下，曲軸不論轉動到什麼位置，都一定有一個一上的汽缸活塞正在出力做功，不再需要飛輪提供的角動能來維繫運轉。因此在四缸以上的發動機，飛輪的主要功能也從維繫發動機的持續運轉，轉移為更加側重於平滑化各汽缸間歇性出力的作用。

那麼照這麼看，四缸以上的發動機是不是運轉速度就可以無限制的慢了呢？答案是不行的！四缸以上的發動機仍然存在著最低的臨界轉速，原因是因為這不是一臺紙面上的理想發動機，而是一臺實際的發動機。發動機仍然需要俱備足夠的功力輸出，來推動那些維持發動機運轉所必須的設備，例如機油泵和冷卻水泵，以及機械運動的摩擦消耗等。此外燃料泵如果供應不足，這油打不上來的話自然就無法正常供油維持運轉；如果不能夠足夠的供應磁電機運作，那麼火星塞將無法點火，自然也是無法持續運轉。總結來說，四缸以上的發動機確實臨界轉速能比四缸以下的情況低很多，但仍舊有個限度，而相比於後者影響臨界轉速的主要因素來自於飛輪，四缸以上發動機的臨界轉速取決於基礎週邊設備的功率供應要求。

這也就是為什麼每當停等紅綠燈的時候，汽車引擎不能夠像電動馬達那樣直接斷供停止，而是必須脫開離合器，並且繼續維持一個很低的基礎轉速而持續運轉的緣故了；否則當綠燈亮起時，就不是簡簡單單的加油門提高轉速就能夠開車，而是必須的重新啟動一次引擎了！而這個在什麼負載都沒有卻為了持續發動機運轉而必須維持的這個狀態，就被稱為「怠速」狀態，對應的轉速自然就是怠速轉速了。只不過為了保險容錯的緣故，一般設定的怠速轉速都是高出理論臨界轉速許多的。

啟動條件

探討完活塞引擎在什麼樣的情況下會無法繼續自力維持並停止運轉的臨界條件之後，現在把狀況反過來，那就是要將一臺停止狀態的活塞引擎啟動到它能夠自力維持的條件了。總的來說就是我們要從外部輸入能量，使用外力驅動發動機的曲軸旋轉，直到它能夠自食其力為止，也就是說外力的驅動在至少達到下列這些條件之前都必須持續供應：

飛輪獲得了足夠的轉動慣性力，至少能夠獨自供應兩個汽缸點火之間空窗期的曲軸動力。
曲軸獲得足夠的轉速，至少能夠供應磁電機產生足夠的點火電力，以及供應燃油泵足夠的抽油壓力。
即便以上條件都達成，也必須供應曲軸至少旋轉約兩圈左右的圈數，直到汽缸完成初始的四循環並開始爆燃產生動力。

總結來說其實最重要的就是，要由外部裝置提供足夠的外力來驅動運轉，渡過發動機無法自立更生的時期，待發動機自己能夠運轉以後，這個外力就可以脫離而不再需要被使用了。至於這個「外力」就被稱為引擎的「啟動裝置」或稱啟動器，當然也是有各式各樣。下面就來看看為了發動一顆引擎，人們都想出了什麼樣的花招？

各種啟動方式

手轉(Hand Propping)

啟動一顆引擎，不就是用外力讓它先轉起來嗎？那麼直接用手來轉動就成了最簡單且直接的方式，也是自打活塞汽油引擎發明以來就被使用的主要啟動方式。

其實這種原始的啟動方式直到現代都還能夠被使用，當然只限於沒有過多電腦參與的使用化油器的發動機，並且還要能手動打檔的車款。也許許多前輩老司機都曾經玩過這樣的操作：將變速箱打至高速檔位，然後推著車子從緩斜坡溜下去，就能夠啟動汽車引擎；如果是摩托車的話可能還不需要斜坡，只要推著助跑一段距離就可以讓引擎發動起來了。這些啟動方式雖然並沒有直觀的用「手」來啟動，但在這裡都歸納為手轉啟動原理的範疇。

Figure 1. 一戰時期的飛機基本全都是用手來啟動的 ^[2]

至於這種啟動方式的缺點，除了看起來不夠科技感之外，也是相當具有危險性！因為活塞引擎的特性，當成功點火發動起來的時候，幾乎是一瞬間就會達到快速暴力運轉的程度，從上面的影片中也可以明顯看得出來這現象。這會使得操作者一旦沒有拿捏好節奏，未能即時收手，那麼造成斷手殘廢的結果都是有可能的！即便是用在沒有螺旋槳的汽車上，因為汽車的重量比較大，所以除非有多名好友一起助力，否則很難能在平地上達成足夠啟動的狀態，所以通常會需要一個往下的斜坡。然而這也同樣昭示了它的風險之所在，以及如果萬一沒能夠一次就成功啟動的後路不多。因此手轉啟動的方式除了在古時候可能是為數不多的方案裡面簡單可靠的方法之外，大多只被用來作為啟動器故障時的最後備用方案。

除了風險的成份之外，手轉啟動還有一個可能更大的問題：當引擎汽缸數量愈來愈多，純靠人力啟動的方式愈發費力且困難；甚至於當螺旋槳造的愈來愈大甚至比人還大的時候，此時就算不在乎危險性，手轉啟動的方案也已經不實際了！

電動馬達啟動器

在現代各式車輛上大家最為熟悉的啟動方式，應該就是使用電動馬達的啟動器了。使用兩顆齒輪，一顆在馬達軸上、一顆在曲軸上，當要啟動的時候使用機械結構將它們結合在一起，不需要的時候把它們分開，這樣就可以使用馬達在啟動階段提供曲軸旋轉動力。在曲軸上的那顆齒輪，通常會和飛輪二合一，如同下圖(Figure 2)所示。

Figure 2. 單缸引擎的啟動馬達與飛輪兼曲軸齒輪 ^[3]

使用電動馬達啟動引擎是一個非常好的方案，啟動速度算快，電動馬達體積也算小，可靠性和故障率都在可接受的範圍內，總體可說是非常方便可靠，也因此才讓現代幾乎所有常用的引擎啟動器用的都是它。那麼有什麼缺點呢？最大的缺點其實是在電源的供應上。馬達本身是不大也不算重，但是能夠供應啟動的足夠電量的電池可就重多了，並且愈大型的發動機所需要的啟動電力也愈多，電池就得更大更重。這對於重量斤斤計較的飛機，特別是那些體型又小又非常在乎性能的戰鬥機來說，為了只在發動之後就不需要的設備增加一堆呆重是很不划算的！也因此才讓我們能看見除了電動馬達以外更多不同的啟動方案被使用在飛機上。

還有些時候人們會另尋思路，既然這個啟動行為只在起飛前需要而已，反正直到降落回來之前發動機都不會再關閉了，那麼我這電池乾脆就不放在飛機上了行嗎？這方案還真可行，而且使用的還挺廣泛，許多老式飛機就是這樣靠著外部的電池或發電機來啟動發動機的；甚至於一直到了現在，很多輕型的噴射戰鬥機仍然需要透過外部輸入的電源(或高壓空氣)來進行啟動。這種藉由外部電源啟動的方式，不只得到了馬達啟動的好處，還省掉了電池的重量，只不過如果不慎在空中熄火的話，要重新發動起來就不是那麼容易的事了！

Figure 3. 一臺連接了外部電源，正準備發動的噴火式戰鬥機 ^[4]

發條啟動器(Spring Starter)

使用一個被壓緊蓄能的彈簧來提供發動機的啟動動力，這就是發條啟動，或也可叫彈簧啟動。這種啟動方式常見於小型和中型的柴油發動機，但在航空器上面基本見不到。發條啟動的好處是結構簡單可靠，體積和重量也都不大，缺點就是在發動之前得先人力上發條，並且隨著彈簧的不斷壓縮，上發條也會愈吃力，這點在下面的影片中可以觀察到。

手搖慣性啟動(Inertia Starter)

慣性啟動器的核心就是一個高速旋轉中的飛輪 (這個飛輪不是我們所認知的活塞引擎裡面的那個曲軸飛輪，而是啟動器自己的飛輪)。當啟動器旋轉的足夠快速以後，用一個離合器將啟動器的飛輪和發動機曲軸連結上，就可以利用啟動器飛輪所蓄積的轉動慣性來驅動發動機啟動。

這種啟動方式乍看之下與前面的發條啟動有點相像，都是在發動之前需要以人力轉動手搖柄來給啟動器蓄能，但是細節有所不同。發條啟動器需要壓縮蓄能彈簧，因此在上發條時需要施加的力氣會愈來愈大，也因此限制了它所能夠應用的發動機尺寸。慣性啟動器的蓄能方式則是質量的旋轉動能，因此即便外部輸入的力量較小，也足以給它持續加速直到所需要的轉速為止，可能因此使得航空飛機更加傾向使用慣性啟動器作為航空活塞發動機的啟動方案吧。如果在現場要分辨兩者的話，那麼發條啟動器在上發條的時候通常可以明顯聽見棘輪發出的卡達聲，並且可以看出操作者轉動搖把是愈轉愈吃力；而慣性啟動器則在一開始的時候比較顯得吃力，愈轉愈快之後看起來操作者的動作會愈來愈順暢，並且啟動器會在高速旋轉狀態下發出嗡嗡聲響。

使用慣性啟動器的好處有簡單可靠、啟動器小巧、不需要電池、並且可以以純人力完成啟動等，缺點則是在每次啟動之前都需要人在飛機外面手搖給啟動器蓄能，如果現場沒有其他幫手，而只有飛行員一個人要自己完成這一切工作的話，會顯得有些麻煩不順利。

此外還有另外一種衍生的啟動方式，使用電動馬達取代手搖，例如在下面影片中所使用的就是這種啟動方案。這種啟動方案和純粹的電動馬達啟動很像，如果要分辨的話，那麼當你聽見明明已經傳出馬達通電轉動的聲音，然後又聽見啟動器飛輪旋轉所發出的並且逐漸變大的嗡嗡聲，但是螺旋槳卻紋絲不動，直到最後離合器卡上之後嗡嗡聲明顯受到影響而快速消減，伴隨螺旋槳在短時間內快速加速並完成發動，那麼這就是使用了電動慣性啟動的情況了！

因為啟動馬達不需要直接帶動曲軸，而使能給啟動器飛輪加速蓄能就好，因此對啟動馬達的功率需求較低，也沒有了需要有人在外面手搖的缺點，可以由駕駛員一人獨立完成操作。缺點就是疊床架屋，本來可以用一個馬達就完成啟動的，它非要中間再加一個啟動器飛輪插手，還多出了增速齒輪和離合器等零件。此外雖然對馬達的功率需求放低了，但啟動所需的總能量卻可能更多或至少理論持平，因此對於電池的需求那是一樣少不了，所以這種啟動方式其實並不多見。

拉繩啟動(Pull Starter)

操作員用手將一條繩索快速抽出就能啟動一臺小型汽油引擎，這種被稱為拉繩啟動的啟動方式也許更為大眾所熟悉，因為許多的小型機械用的就是這種啟動方案，如割草機、鏈鋸等。

拉繩啟動在原理上其實屬於慣性啟動的衍生近親，只不過當發動機體型小到某種程度以後，也就不需要相對複雜的飛輪、增速齒輪、離合器等這些設備了，因為人的手臂已經具有足夠的力量可以直接驅動曲軸快速旋轉起來。因此只需要一條纏繞的繩索輔助，讓人可以像是打陀螺那樣的原理直接去抽動它，就足以完成啟動了。

壓縮空氣啟動(Compressed-Air Starter)

使用壓縮空氣的啟動方式在邏輯上與電動馬達啟動方案非常相像，只不過將電動馬達換成氣動馬達，電池換成壓縮空氣罐而已。氣動馬達的原理如下面影片所示，就是讓高壓空氣吹過渦輪並驅動軸心旋轉而已。

使用壓縮空氣啟動方案的好處與電動馬達相似，操作快捷方便，可以單人完成；雖然需要攜帶壓縮器瓶，但肯定比相應的電池重量輕多了！最大的缺點就是需要額外裝備一臺空氣壓縮機，好在發動機正常運作的時候透過分走引擎曲軸的動力來壓縮空氣補充氣瓶，並且給壓縮氣瓶充氣所需要消耗的能量並不比充電少，也更加不方便。什麼你說採用電動馬達方案也是一樣要給電池充電嗎？是這麼說沒錯，但其實發動機本來就都有裝備小型發電機的，畢竟飛機上一大堆的機上設備本來也都是靠這臺發電機來供電，因此並不需要「額外」增加一個發電機；但是給氣瓶充氣卻需要額外裝載空氣壓縮機，並且壓縮機的重量可比發電機重多了！

不過如果在設計上就沒有想要讓飛機可以憑自身能力補充壓縮空氣的話，如果在規劃上就認為只要飛回基地後使用基地的壓縮機來補充壓縮氣就好的話，那麼倒是也就可以省掉這個壓縮機的裝載需求。甚至於壓縮氣瓶也可以不放在飛機上，反正也只是發動的時候需要使用而已，只要能夠接受每次啟動的時候都依賴地面的氣源設備的話，那麼就連壓縮氣瓶的體積和重量都可以省掉了！

考夫曼啟動器(Coffman Starter)

最後來看一種挺特別的，又被暱稱叫作霰彈槍啟動器的考夫曼啟動器。

這種啟動方案從原理上來看其實也算是壓縮空氣啟動的衍生。使用壓縮空氣來啟動發動機，哪哪都好，就是壓縮空氣的儲存與製備挺讓人頭疼。那麼有沒有什麼東西可以在短時間之內快速產生大量的壓縮氣體，但是在此之前卻能夠方便保存運送的呢？東西當然是有的，於是人們將目光看向了火藥！而這其實就是考夫曼啟動器的核心原理：將火藥引燃後，利用產生的大量高壓氣體去推動氣動馬達旋轉。

考夫曼啟動方案的優點就是設備輕量、小巧、緊緻、操作便捷、啟動速度還賊快！不需要電池，不需要壓縮氣瓶，不需要壓縮機，更不用人在外面搖轉手柄，只是每次啟動都需要消耗掉一個像子彈的火藥罐，並且飛在天上的時候無法補充。雖然說這火藥罐每次啟動就需要消耗一個，但是它又小又容易保存和運送，在基地裡面可以一箱一箱的量大管夠，好像也不是什麼太大的問題。因此考夫曼啟動器曾被大量應用在各種軍用航空器上面，反倒是在民用用途上因為火藥的管制問題而不多見。

作為這個盛裝火藥的藥罐，雖然乍看挺向霰彈子彈的，啟動的時候也是真的像開槍一樣會發出「砰」的聲音，因此被暱稱為霰彈槍啟動器。但是這東西和真正的霰彈又是完全不同的東西，更不可能混用！啟動器的火藥罐體型上就比一般的霰彈大了一倍以上，並且裡面沒有彈頭，只有純發射藥；至於點火的方式，有的採用底火擊發，而有的採用電子擊發。

1. 活塞引擎 1：認識活塞引擎

2. Old ROTARY vs RADIAL Engines Cold Start Smoke and Sound

3. 汽缸大不同

4. SUPERMARINE SPITFIRE, AIR MINISTRY COCKPIT GENERATOR SWITCH

活塞引擎 13：化油器與油門

Sat, 01 Mar 2025 13:03:15 +0800

這次來看一個在傳統活塞引擎上也算是非常有意思的東西：化油器。它體積並不大，乍看之下也只是小小一個東西，卻是在整個引擎的運作過程中起到控制作用的重要元件。

Figure 1. 化油器外觀 ^[1]

不知讀者中有沒有人有過這樣的疑惑，在前面的文章裡，我總是說空氣和燃料混合在一起成為混合氣，簡稱「油氣」，卻好像一直沒有交代這油是怎麼和空氣給均勻混合一起的？而這就是化油器存在的目的。

其實在現代車輛中已經幾乎看不見化油器了，當代各種發動機多半總是更喜歡使用高壓泵，將燃料推擠從針孔大小的孔洞給噴射出來變成霧氣，直接往吸進來的空氣裡面噴霧，就完成了。這就是現代所謂的「燃油噴射」霧化技術。燃油直接噴射霧化是挺美好的，但是相關設備比較精密昂貴，還需要能夠提供更大壓力的高壓泵、及能夠承受高壓的燃油管路，因此成本較高。此外往往還需要各種調較和控制機制才能夠使它正確穩定的工作，當然這部份在當代行車電腦發達普遍的情況下並不是什麼大問題，不過對於古時候的人來說就很吃力了。除了相關的精密零件設備導致成本較高之外，在沒有近代電控輔助的情況下，使用純機械的方式控制噴油量也是很難做到恰到好處的精準的 (因此以前的柴油引擎也比較容易排黑煙)。在直到近代這二十年左右的時間之前，人們必須採用另外一種更加簡單、廉價、又可靠的方式來進行油氣混合，也就是本篇的主題：化油器。不過即便是在現代，也不是所有的活塞發動機都能夠用上電腦控制和燃油噴射的，比如說那些有體積和成本限制的割草機、卡丁車、小型發電機、航模引擎等等，仍舊能見到化油器在它們身上默默工作著。

化油器原理

Figure 2. 化油器結構圖 ^[1]

其實化油器的主體結構非常非常簡單，如上圖(Figure 2)所示，就是一個管子，從外面進來的空氣可以直接通過，就是管子中間有個縮口設計而已。然後不論是白努利、還是文氏管原理都告訴我們，空氣在經過縮口的時候速度會變快、壓力會變低，於是就把縮口當中一個小縫管路裡的油給吸出來霧化，和經過的空氣自然混合一起了。這就和一些噴漆罐如何將油漆打散成小顆粒並和空氣混合噴務而出的原理是一樣的。

了解了化油器的核心原理之後，可能會發現在實現上這種裝置的作用必須仰賴油管的油壓穩定且恆定。否則油壓太高會導致過多的燃料過多流出，甚至沒等被空氣吸出去就自己先以液體狀態流入氣管，另一方面若油壓太低則會導致不容易被吸出，甚至可能吸不到油。這就是為什麼化油器旁邊要有一個小輔助油箱的原因了，先將汽油適量的從油箱抽入這個輔助油箱裡，藉著控制輔助油箱的液面維持在穩定的位置，從而穩定狹管內的液體壓力。不過這樣的設計也從根本上給了它一個嚴重的缺陷：它的正常工作往往仰賴穩定的重力狀態。如果車子準備爬個大陡坡，比如 45 度的那種，或者要衝個大下坡，或者要上下翻兩圈、或者玩自由落體等等，就容易使化油器供油不穩定，容易過量供油、或者斷油熄火。當然車子要這麼玩是有點誇張了，可是放到飛機上，特別是戰鬥機上面……，這就是為什麼二戰時期那些採用化油器的戰機在做垂直俯衝等過激動做的時候容易斷油熄火的原因了！

功率控制

不論汽車、飛機、還是船舶，都有一個很重要的需求，就是要能夠控制發動機的輸出功率大小，而不是一啟動就工作在最大功率狀態直到熄火為止。這就是油門的目的了，是用來即時的、大高低跨度的控制發動機輸出功率的主要設備。

我們都說油門油門，感覺好像就是依靠調整注油量來控制引擎的出力，然而實際上並不是。其實我在往期的文章也解釋過了，注油的量確實可以高低調整，但是能夠調整的範圍其實非常有限。油噴太多了浪費，畢竟汽缸裡的空氣就那麼多、氧就那麼多，把氧耗完之後多出來的油都是白白噴掉的；油噴太少了則會讓點火困難，甚至過於稀薄的油氣無法被點燃。因此通常來說，噴油的量其實並不太能夠大範圍調整，只要汽缸裡面的活塞抽氣了，那麼該噴多少油進去就要噴多少油進去，無論當下油門到底是整個鬆開的還是已經被踩到底的！最終每次灌注進入汽缸內的注油量確實是可以調整的，但那都是基於別的目的要調整油氣濃度所產生的行為，而如果要依賴此注油量的高低來控制引擎出力大小的話，那麼只能說是非常不實用的！

Figure 3. 化油器中的節氣門(throttle valve)與阻風門(choke valve) ^[1]

那麼我們基於大範圍調整功率輸出的目的到底該如何進行控制呢？主要還是得透過控制曲軸的轉速這個方式來進行。那麼人們都怎麼控制曲軸轉速呢？除了使用變速箱來調整曲軸負載以控制轉速之外，基本上所有活塞式發動機都是依靠調整進氣管的進氣阻力來達成的，也就是在上圖(Figure 3)化油器的下游處有一個被標示為 throttle 的閥門在控制的。這個閥門就是「節氣門」(throttle valve)，它的開關程度會造成不一樣的管路阻力，全開的時候油氣可以完全順暢的通過，而接近全關的時候(不會完全關閉的程度，否則沒氣就得熄火了)油氣的流動阻力最大。藉由控制進氣管不同程度的流動阻力，它影響的其實是汽缸在進氣行程時候的吸氣阻力，是用刻意增加的吸氣阻力來調整進氣時油氣充填的速度，使活塞因為阻力變大而慢下來。這其實就和往期文章在探討進排氣阻力 ^[2] 的原理是一模一樣的，不同的是從前探討的是發動機在極限轉速之下所遭遇的氣體流動阻力問題，而現在這個是為了讓發動機能夠不要那麼賣力工作而人工主動加入的氣體流動阻力。

但另一方面，節氣門半開時所造成的人工氣流阻力確實會內耗發動機的動力，就如同使用電阻來控制燈泡的亮度一樣會導致一部份電能在電阻上被消耗掉。所以使用節氣門來調降發動機輸出功率的同時，也會消耗掉發動機的功率(節氣門開的愈小則消耗的比例愈多)，導致燃油效率降低。但是兩害相權取其輕，當我們需要低功率輸出的時候，比方說在慢速航行、或停車怠速的時候，雖然這時引擎的效率低，但是因為轉速也同樣受限而降低，因此燃油的消耗速度更慢了；比起讓它高效運作然後嘩嘩燒油，顯然這時候讓它處在低效狀態但是燃油燒慢一點是更好的。

另外，這也是為什麼發動機的最高效工作轉速位在中間某個位置的原因，因為在轉速偏高時會遭遇各種「喘不過氣」 ^[3] 的阻礙而導致效率降低，而某個程度以下的低轉速多半是靠節氣門來控制的，此時節氣門的氣流阻力消耗成為效率降低的主要元兇。那麼意思是不是說，如果節氣門全開，但是仍然維持低轉速的話，是不是就是真正燃油效率最高的狀態了呢？這還真是這樣沒錯！這就要說到除了節氣門之外能夠有效控制發動機轉速的另一個設備：變速箱。變速箱通過調整曲軸的負荷力道來控制 — 或者更精確的說其實是適配 — 曲軸轉速，不過有關變速箱以及其相關的內容已經超出了本系列所設定的主題，因此不會多談。

如果要最大化發動機的燃油效率，那麼曲軸的轉速就要愈低愈好，能夠最大程度減小「喘不過氣」所造成的消耗。並且節氣門也要在全開的狀態，以完全消除節氣門本身的消耗，並且同時還要維持低轉速。因此最後還需要給發動機掛上一個很大的後端負載，用通俗白話文來說就是變速箱要掛在最高檔位上，才能完全符合前面所設定的所有條件，而此時也將是發動機理論上能夠達到最高燃油效率的時候。當然這是一個過度理想並且完全忽略了實用性需求的結果，它排除了在此運轉狀態下馬力低，導致加速性不佳，可能隨便一個小坡都能讓車爬不上去的實用性問題，也同樣不考慮發動機的結構承受能力、以及是否容易造成損壞的耐用性等等問題。

油氣濃度控制

在上面的化油器原理示意圖中(Figure 3)，我們可以看到長的像節氣門那樣的閥門有兩個。其實這兩個閥門是一模一樣的，只不過名字不一樣，一個在上游、一個在下游，下游那個就是剛剛介紹過的節氣門，而上游的則叫作「阻風門」(choke valve)。阻風門的動作原理與節氣門一模一樣，都是人工增加氣流阻力的裝置，不過在噴油管上游的這個閥門有一個很重要的作用：控制油氣混合的濃度。

當後面的活塞和汽缸在工作狀態的時候，它們是不斷在從進氣管大量抽氣的，也就是說化油器這邊管路內的空氣是受到後面一股力量在抽取。而當位於上游的阻風門半開的時候，會導致後方噴油管那裡的空氣壓力降低且密度降低。也就是說假設同樣份量的汽油被吸出油管並霧化到空氣中，但是這時通過的空氣份量少了，於是油的佔比(濃度)就提高了。

油氣濃度控制，對於大部份的汽車駕駛來說可能比較陌生，因為一般來說只有在可能比較注重性能的車款，才可能會在比較隱密的某個角落，出現有可被駕駛員控制的油氣濃度控制器。可是在飛機上，油氣濃度控制可是一個經常會需要被調節的東西，以至於和油門擺在一起成為駕駛員伸手最容易控制的位置(雖然比起油門，它的位階還是明顯低一些)。為什麼呢？除了有時候可能因為需要長距離飛行而刻意調低油氣濃度以提高燃油效率之外，最主要的原因還是因為飛機的飛行高度變動範圍太大的緣故。當飛機的飛行高度愈來愈高，吸入的空氣壓力和密度也會愈來愈低 (即便可能有增壓器的幫忙，進氣的壓力與密度仍然是隨高度逐漸降低的，只是趨勢比較平緩些)，那麼汽缸內氧氣的含量也是逐漸降低。這時候對於地面上正巧足夠的油氣濃度在高空中就會顯得過濃，造成很大一部份並不能夠參與燃燒而被浪費掉，因此通常來說就會需要隨著飛行高度的變化而不斷調整供油濃度。

下圖(Figure 4)就是 P-51 戰鬥機駕駛艙，圖中標記的就是操作頻率最高的三個控制器的位置：油門(飛機上可能更喜歡叫「節流閥」)、螺距、與油氣濃度控制器。通常在正常飛行的姿勢下，駕駛員的右手握著雙腿中間的操縱桿，而左手就放在節流閥上面。上面的照片可能對一般並不熟悉飛機駕駛艙的人來說顯得不容易看清楚，那麼下圖(Figure 5)就是三個主要控制器的模型，雖不完全是與上圖同一個零件，但是對於初次認識飛機上的控制器的人來說已是足夠理解了。這控制器上有三個把手可以往前推或往後拉，最左邊那個把手最大的那根桿就是節流閥，也就是通俗所稱的油門，往前推則油門加大；最右邊紅色把手的桿就是油氣濃度控制桿，往前推則油氣濃度高；中間的桿是用來控制螺旋槳螺距與轉速，可以理解為與汽車上的排檔桿作用相同，往前推則螺旋槳轉速高、即檔位低。

Figure 4. P-51 戰鬥機座艙內的油門控制器位置 ^[4]

Figure 5. 戰鬥機油門控制器模型 ^[5]

總結

解釋完化油器的基本原理與相關的操作邏輯，其實在實務產品上還有一些其它的細節就不深入探討了。比如說突然猛加油門的時候，汽油因為慣性的緣故還來不及被增量吸入，而導致瞬間油氣過稀的問題等；或者在倒飛的時候如何使附掛小油箱能夠正常工作的問題等等。為了這些問題，其實在實用的化油器上面可能還打了許多相關的補丁 (當然廉價或早期產品可能就沒有了，所以老車突然大油門的操作可能會導致熄火)，但是也仍有許多東西它只能一定程度的改善而無法完全處理好，例如如果要精確控制每次吸入的燃油量的話。而這些方方面面的問題與補丁都在昭示著化油器最大的根本性問題：穩定性不足，不容易精細控制。

化油器本身的簡單和使用門檻低的特性，使得在人類技術積累還不足的時代可以立刻承擔使活塞發動機能夠工作的關鍵角色，但是當人類不斷在性能、燃油經濟性等方面吹毛求疵的時候，它的瓶頸限制就逐漸顯露出來了。這就是為什麼後來噴霧注射會逐漸取代化油器的原因了。雖然成本和技術難度都提高，但是它靈活且精準，在電腦和感測器的作用下，每次噴多少油或甚至不噴油等就都是精確可控的。

1. Carburetor

2. 活塞引擎 9：功效分析之走入現實

3. 活塞引擎 10：功率巔峰

4. P-51D Mustang Product Info

5. 3D Printable Saitek Quadrant - P-47 Bracket & Levers by Wayne Dickinson

活塞引擎 12：追求效率，阿金森與米勒

Sat, 22 Feb 2025 10:48:50 +0800

在用了幾集的篇幅追逐大功率和爆發力之後，這次要轉換個心情，從另一個視角來看看在給汽油引擎增加燃油效率的巧思。這次要介紹的是在現代才開始逐漸實用化的，大幅提升燃油效率的設計概念： Atkinson 和 Miller 動力結構。

這次要介紹的這兩種設計思想，其實目的都是在解決同一個問題：活塞引擎的膨脹率！

傳統(即 Otto 型式)汽油發動機有一個蠻大的結構性損失，因為活塞行程距離固定的關係，其壓縮和膨脹是對稱的。在我往期的分析內容 ^[1] 就已經可以明顯看出一個現象，氣體被加熱之後明顯具有更大的膨脹能力，其能夠膨脹的體積比加熱前被壓縮的程度明顯超出一截。然而因為活塞、連桿、和曲軸等機械的結構特性和運作方式的原因，造成總是有最後一段的膨脹力沒辦法被捕捉利用的結果，再參考我往期的分析內容 ^[2] 就能知道，被這麼眼睜睜的看著放走的能量可能佔到 8.5% 的比例；意思就是說如果我們能想個辦法把這些能量給捕捉下來的話，那麼最多可以給發動機帶來約 9% 的效率增長，對比人們採用的各種增進效率的其它技術以及其所能之改進幅度，這種概念如果能夠實現的話肯定效益菲淺！

那麼這個想法概念如何成為實際的方案呢？這就得看那些機械天才們的奇思妙想了！然而各種天馬行空的想法與設計，其概念與目標是一樣的： 讓氣體可以充份膨脹；讓活塞在膨脹行程可以跑的比壓縮行程更遠！

阿金森(Atkinson)

Figure 1. Atkinson engine, 1882 ^[3]

Figure 2. Atkinson engine, 1887 ^[3]

這種方案最早是由 James Atkinson 在 1882 年 ^[3] 所實現出來的，所以被稱為阿金森循環。其核心原理是使用巧妙的機械結構設計，直接讓活塞在不同的行程中移動不一樣的距離，根本性的提供壓縮和膨脹行程兩個不一樣的行程距離，直接解決所有的問題！

不過我想稍微熟悉發動機的人可能已經發現這個方案的最大缺點了，其複雜的機械結構和龐大的體積(當然都是相對於經典的 Daimler 四行程結構來說)，使得在特別是交通工具上的應用存在嚴重的劣勢。我想這應該就是為什麼這種結構明明早在 1882 年就已被發明，卻直到現代才在車輛領域有所實際應用的原因之一吧；更別說在航空領域更是從來就沒見過這種東西！

米勒(Miller)

Figure 3. Miller engine ^[4]

這種方案最早是由 Ralph Miller 在 1957 年所實現出來 ^[5] ，所以被稱微米勒循環。其結構與傳統四行程發動機完全一模一樣，只不過改變了進氣閥門的開關時機，就這麼完成了所有的工作！在通常一般的四行程運作中(暫不考慮汽門正時，只以完全理想情況來說)，進氣行程活塞走到底的時候，進氣閥就關起來了，而米勒則讓它維持開啟狀態久一點。在原本應該要是壓縮的行程中，進氣閥在大約開始的 20% ~ 30% 行程時間裡都是開啟的，因此會有好一部份油氣被反向從進氣閥給推出去；然後後面的步驟就與傳統四行程完全一樣了，一切照舊。

就是這麼簡單的一個改動(當然是相對於已經既存的大量四行程設計來說)，達到了壓縮率與膨脹率不同的效果，使膨脹行程的膨脹率大於壓縮行程的壓縮率一截。於是這個方案的優點就非常明顯了，與阿金森形式相比沒有那麼多複雜的結構，也不用面對結構體積膨脹及如何緊湊化的問題，甚至於可以大量沿用許多早已實現多年且非常成熟的既有設計和相關實驗資料，而所需要改變的東西僅僅只是進氣門開關的時機而已。因此米勒式的發動機結構在現代被大量採用在許多「需要」的應用上。至於既然這種設計這麼簡單純粹，為什麼直到 1957 年才被發明出來呢？這就是我們後人才能夠問出來的事後諸葛亮式的疑問了！這就好比在 Otto 之前，你能想出來在燃燒之前先把空氣壓一壓再燒比較好嗎？又好比在迴紋針被發明出來之前，你能想的到原來鐵絲可以這樣繞一繞就能賣錢嗎？

不過米勒動力結構還有一個缺點。因為它並沒有像阿金森那樣設計機械結構，壓縮行程中活塞的實際移動距離是不變的，僅以改變汽門開關時間的手段來達到目的，而這導致了有一部份油氣會在進入汽缸後再被反向推回油管。首先這導致管道內的油氣不斷來回移動，除了使燃油濃度在控制上更加複雜外(對於非缸內直噴來說)，如果前面有增壓器的話，更會導致增壓器的回壓來回動盪，如果再剛好增壓器工作強度不足則更可能使氣體在增壓器內反向倒流，形成喘振！

對於這個問題在理論上有簡單的解決方法，比如我正常的米勒設計是延遲進氣門關閉時間，那我如果改成提早關閉進氣門呢？在進氣行程才走到 70% ~ 80 % 的時候就先關閉汽門，然後後面照舊，這樣有效的壓縮行程同樣縮小了，卻不會造成油氣回流的問題。這種想法確實有用，也確實有人這麼做，只不過實現上有些困難挑戰性。回過頭來看一下一般常見的汽缸頭氣閥和管道如下圖(Figure 4)，一般的氣閥設計可以很有效的抵抗缸內高壓，但如果外面管路壓力比缸內壓力還大的話，就只能全靠那根彈簧來支撐了，而這正是採用提前關閉進氣門方案所需要面對的情況，可能也是米勒當時為什麼寧願讓油氣回流也要採用延遲關閉進氣門方案的原因吧！最終採用提前關閉進氣門的方式來實現米勒循環的方案並非不可行，但可能會需要重新設計進氣門的結構。

Figure 4. 汽缸頭的閥門和進氣與排氣管特寫 ^[6]

觀念澄清

網路上有很多相關文章和影片，在介紹米勒或阿金森這些運作方式的時候，都喜歡說「它們縮短了壓縮油氣時的活塞行程，降低了壓縮比，因此提高了效率！」其實從前面的介紹來看，還真不能夠說這種解釋錯了，但是我並不喜歡這種說法，因為它會使人感到困惑：「以前不是說提高壓縮比可以增加效率嗎？不是那個什麼廠啊什麼廠的還強調他們把壓縮率提高到多少，所以提升了燃油效率嗎？怎麼現在降低壓縮比也增加效率了？那麼到底是提高壓縮比能增進燃油效率？還是降低壓縮比可以增進燃油效率啊？搞得好亂啊！」

我想如果是從本系列文章一路看過來的讀者，到這裡已經知道箇中奧妙了！其實根本重點不在於降低壓縮比，而是增加膨脹比；至於壓縮比則是實際上文絲未動。對於增加效率來說，當然壓縮比是愈大愈好。不論是阿金森還是米勒的方案，都是取來一個壓縮比更大的汽缸，然後在此基礎上去縮減壓縮時的活塞有效行程，減少壓縮比。但這樣一來一回之下其實最終壓縮比並沒變動，而是膨脹比增加了；是膨脹行程的增加而使得氣體膨脹的能量能被更加完整的捕捉下來，從而提高效率。

所以不論阿金森或米勒、或可能存在的其它方案，核心原理都是靠著增加膨脹週期的活塞行程距離來增加燃油效率。那麼為什麼就能這麼篤定壓縮比不會變動呢？壓縮比肯定不會有變化。因為壓縮比如果實質的降低了，那麼燃燒效率也會降低，而且可能降低的幅度更甚於增加膨脹比所帶來的好處 ^[1]，因此沒有腦袋正常的設計者會想要無緣無故去降低實質壓縮比。那麼為什麼不增加壓縮比呢？增加壓縮比確實可以大幅改善效能，而且其實大家無一不想提高壓縮比，耐何提高不了。因為汽油的化學性質擺在那，再提高下去就要爆震了 ^[2]！最終的重點就是，不論任何複雜的機械結構方案還是各種天花亂墜的動畫演示，現在你知道它們其實根本沒有變動壓縮比，而是延伸了膨脹行程，增加了膨脹比。

缺點軟肋

在前面的介紹中不知道有沒有發現一件事？ Atkinson 動力結構早在 1882 年就被發明出來了，甚至還比 Daimler 的汽油引擎早一年。如果要說阿金森的結構比較花俏而質疑其實用性的話，那麼 Miller 的方案也在 1957 年就出來了。那為什麼在直到最近十餘年的時間，才開始在大眾視野見到使用了這些動力結構方案的產品出現呢？這就要說到這些動力方案的缺點了……

最直接肉眼可見的缺點就是此類發動機體積會比別人稍大一些，這是因為為了要延伸活塞膨脹行程的長度而導致汽缸會比較長的結果。

第二個缺點是發動機馬力較低。其實在往期文章 ^[7] 就有提及這類機械結構的缺點。為了能夠更加完整的捕捉氣體膨脹的動力，而增加了活塞在膨脹行程的行程長度，但是我從前也實際計算過 ^[1]，在氣體膨脹過程的尾端其實壓力已經處在低檔，推動活塞的力量已然不多，是真正處在強弩之末。因此這類發動機的曲軸轉速會受到限制而降低，其降低的原因主要有二：其一是因為受制於活塞移動速度，更長的活塞行程自然導致曲軸轉速下降 ^[7]；其二就是上面提到的，因為氣體壓力在尾端的推動力已經所剩不多 ^[1]，推力不足自然就推不快了。無論如何，轉速降低的結果就是讓發動機的馬力同樣下降，因此不論是採用了阿金森還是米勒方案的發動機，其相比於同體量同排量的其它發動機一定是馬力比別人低的。這些結果又再體現了那句話： 功率和效率往往是互相衝突的兩個指標！ ^[8]

此外這種延長了膨脹行程的發動機還使得另一項東西的地位顯得有些尷尬，那就是排氣渦輪！回顧前篇才介紹過的排氣渦輪 ^[9] ，它最大的優勢就是不需要額外耗費發動機的動力就可以自己運作。然而這項優點的背後，其實是來自於使用了那些原本無法被汽缸活塞擷取而被放走的能量作為驅動力的結果。反正那些動力不拿來使用的話也只是浪費排掉，因此才造成了排氣渦輪好像可以像永動機一樣自己動起來的樣子。但是現在可好了，延長了膨脹行程的發動機可以更大程度的捕捉到這些能量，給活塞汽缸自己是得到了更多動力沒錯，但是留給排氣渦輪的排氣動力就只剩老弱殘兵了。因此觀察當前車市應也能發現此一現象，那些裝備了排氣渦輪設備的發動機基本看不到使用阿金森或米勒的運作結構，而採用了阿金森或米勒運作方式的發動機基本不會同時裝上排氣渦輪增壓設備；如果非得需要增壓的話，那麼多半採用的也是軸驅增壓。

發展應用

像米勒或阿金森這樣的結構雖然提高了燃油效率，但在功率輸出表現上卻佔劣勢，使得這類發動機更加適合的是需要高效穩定輸出功率的應用場合，比如發電機。然而在需要運動能力和爆發能力的交通工具應用領域上就顯得很吃虧了。你總不會希望在需要加速超車的時候、或者需要加速逃命的時候，一腳油門踩下去結果發動機還沒力吧！？再加上曾經的油價相比現在廉價許多，對於這點效能的提升往往並不被人看重，反而它的功率和性能表現不佳這點倒是讓人無法忽略。因此就讓這些想法概念雖然誕生的早，確總是遭到雪藏冷落的命運了！

既然如此這般，已經可以理解為什麼這類型發動機在過往不受待見，但為什麼又在最近十來年突然就出現在大眾視野，開始普及了呢？這主要歸功於時代環境的變化。在油價高漲的現今，加上越發嚴苛的環保要求，因此燃油效率愈來愈受到重視，使研發人不斷想方設法絞盡腦汁要從各方面提升效率。最後則是油電複合動力車輛的出現與普及給它掃清了最後一道障礙。在油電複合車上，內燃機與電機共同承擔車輛所需的動力，在短暫需要大功率的時候可以依賴電馬達更多的輸出，因此比較能夠容忍米勒和阿金森型式帶來的馬力減損，並更加看中它們的燃油效率。特別是那些在中國大陸稱為「插電混動」式的車輛，推進基本只靠電馬達，而內燃機則在絕大多數時候只是一個充當發電機的供電角色，那麼自然它的爆發力不足這件事就無傷大雅，反而它能以較高的燃油效率穩定工作這點特性顯得更加吃香。所以才造成了這麼一個結果，這些早已被發明出來卻一直不受待見而被雪藏的技術，在複合動力車輛盛行的當代卻得以撥雲見日，迎來能夠一展長才的時刻。

說完了汽車，那飛機呢？很不幸的，這種動力結構在航空器的領域上很難得到發展的空間！因為飛機對於重量是非常斤斤計較的，阿金森和米勒式的發動機雖然燃油效率是比一般傳統活塞內燃機高了不少，但是體積重量都比同排量傳統汽油引擎微幅增加，然而馬力卻更低。那麼為了要支撐一架飛機飛上天，就得選用更大的引擎，於是這重量又更大了。更大的重量帶來的負擔和更多的油耗，可能比不過它省下來的油之外還得倒賠！因此這類發動機目前為止在航空的領域並沒有它的一席之地。

1. 活塞引擎 8：功效分析之基礎原理

2. 活塞引擎 9：功效分析之走入現實

3. Atkinson cycle

4. Volkswagen’s 1.5L Miller Cycle Engine: How Does it Work?

5. Miller cycle

6. 規格表數據解密！教你看懂規格表沒說的事！

7. 活塞引擎 10：功率巔峰

8. 活塞引擎 7：功率與效率

9. 活塞引擎 11：渦輪增壓

活塞引擎 11：渦輪增壓

Mon, 17 Feb 2025 19:46:00 +0800

這次要來說說增壓裝置的話題。渦輪增壓如今早已不是什麼稀奇罕見的高科技產品，在許多民用房車上都能見到它的身影，其廣泛流通的程度甚至早已成為尋常可見的東西。但有沒有想過，就這麼小小的一個附加裝置竟然能夠大幅度提升汽車引擎的動力，其提升程度幾乎讓所有其它技術改進方案在它的面前都成了小弟。本篇我就要來聊聊在活塞引擎上加入渦輪增壓的話題。

高空的稀薄空氣

若是回到最初在航空領域上面的應用則又是另一番光景，它在航空飛機上開始的故事倒不是為了增加馬力什麼的，而是為了一個很卑微又很現實的需求：希望上了空氣稀薄的天空時，動力能夠不要衰弱的太慘！

飛機上了高空發生什麼事情呢？我們知道愈往高空走這空氣愈加稀薄，翻譯成我們分析發動機時聽得懂的用語，就是高度愈高則氣壓愈低、密度愈低、溫度也愈低 (以上幾點至少在人類飛機一般正常能夠飛到的高度內是如此)。若拿起在前篇 ^[1] 使用過的分析方法來分析發動機在如此環境下的性能表現，就會發現當進氣時氣壓愈低，則發動機的功率輸出也愈低，其功率降低的幅度大約與吸氣壓力降低的比例相同。

然而情況卻並不僅止於此。當氣壓降低的時候，空氣的密度也同樣在降低，這表示汽缸一次吸入的氣體雖然體積是一樣的，但是氣體總質量降低了。這有什麼問題呢？氣體的量降低了就表示連帶內含的氧氣份量也降低，也就是說真正能夠參與氧化反應的燃料量也會同樣下降，如果在高空和在地面一樣噴入同樣份量的汽油的話，那麼其中一大部份顯然並不能得到與氧結合的機會，也就是說許多的燃料會被平白浪費掉！當然我們通常不會這麼蠢，通常駕駛員會相應的降低油氣混合比例，反正多噴的油也是浪費。

這麼一套下來的結果，在高空氣壓降低本身已經能使發動機的輸出功率降低，空氣密度的降低又使得我們必須得少噴點油，便再進一步下調動力輸出。最終發動機功率與飛行高度的變化關係整理如下圖(Figure 1)所示。

Tip	Figure 1 採用與前篇 ^[1] 相同的計算方式，採用理想條件 9 倍壓縮比的計算案例參數，隨動的變數只有吸氣時的空氣狀態變化 ^[2] ，以及隨同吸氣密度的變化等比調整升溫幅度。並且為了更好的比較幾個不同參數隨高度而變化的幅度，各參數並不是以原始值的大小來繪製圖表，而是表示以與相對於地面高度時的值的比例。例如圖表顯示氣壓在約 8000 公尺高度下的壓力約為 0.4，意思是指該高度下的壓力只有高度 0 時氣壓的 0.4 倍。

Figure 1. 發動機功率與高度變化趨勢

從上面的圖表可以觀察出，如果不考慮其它手段的輔助，發動機的功率在飛行高度來到 3000 公尺時就只剩下一半了，到了 9000 公尺時只剩下兩成。當然這只是單純只看發動機的功率表現變化，至於飛機的具體升限還得由飛機整體的綜合設計來決定，例如動力在扣掉飛行基本所需之後究竟還「多餘」了多少、又例如機翼本身在地面和高空的性能表現如何等等；不過在本篇將只聚焦在發動機的性能影響上面就是了！

既然飛行高度愈高則發動機功率直落，那麼我們該怎麼辦呢？顯然現代的我們知道人類對此問題的解決辦法，就是在高空給發動機製造一個高壓的進氣條件，而對於這個方案我們所需要的就是一個小附加裝置：增壓器。有了增壓器的存在，在高空稀薄的大氣中飛行，它能夠吸入大量空氣然後加壓空氣，壓縮後再把空氣送進汽缸內，再之後就是我們已經知道的事情了。空氣壓縮器的作用效果在於，如果說它能將進氣的壓力給增加個 3 倍(當然假設密度也是同等上升)，那麼就能讓發動機在 6000 公尺高度上的表現和地面上相差不大；換句話說，飛機的升限能夠因此更加提高，而發動機在那樣高空的性能表現依然不俗！ (當然這是只看發動機的情況，至於整機的性能還和飛機上很多其它東西在高空的表現有關。)

渦輪增壓器簡介

其實壓縮機有許多種不同原理與形式的實現，甚至於前面好幾篇在解說的活塞汽缸其實也是壓縮器的一種實現方式，不過在本篇我將只專注於離心渦輪壓縮機的內容。

Figure 2. 離心渦輪增壓器 ^[3] ^[4]

Figure 3. 離心渦輪的葉輪 ^[5] ^[4]

上圖(Figure 2)這東西就是渦輪壓縮器，因為形狀酷似蛙牛的關係，也有人暱稱它較小蛙牛。其內部最重要的，也是唯一會活動的主要零件，就是上圖(Figure 3)被稱為「葉輪」的零件。當葉輪高速旋轉起來(以上圖(Figure 3)的葉輪來說是逆時鐘旋轉)，中心會從前方吸入外界的空氣到葉輪內，然後空氣被葉輪推動著一起旋轉起來。空氣在旋轉的過程中會一路往外圈被推著跑，最後被推送到最外圈的環狀通道內被收集起來，整流過後集中從一處切線方向的出口吹出去。至此完成空氣在增壓器內的流動過程。

稍微仔細點說明其中原理，空氣在從葉輪中心往外圈的路程上會受到兩股力量的作用，一個是切線方向的加速力，一個是徑向的離心力。徑向離心力(如下圖 Figure 4 的綠色箭頭所示)作用在空氣上除了推動空氣往外圈跑之外，也是這時候空氣被壓縮的主要力量來源。另一邊沿著繞圓的切線方向(如下圖 Figure 4 的藍色箭頭所示)的力作用在空氣身上，使得吸入的空氣被加速跟著繞圓旋轉；而且因為空氣同時一直在順著徑向方向往外圓移動，所以不斷會有新來的空氣需要被加速旋轉起來。這個加速的力道就是物理圓周運動中的「科氏力」，而其之反作用力同時也是葉輪旋轉的最大阻力來源。

Figure 4. 氣流在葉輪內的流動方向 ^[6] ^[4]

當空氣從葉輪最外圍離開的時候，其不只被進行了一定程度的增壓，還同時帶有與葉輪尖端速度相同的切線方向速度，速度相當高。空氣離開葉輪後就會進入外面的環狀通道，這個通道的作用除了收集氣體使其最後從一個固定的方向流出之外，還同時具有將剛離開葉輪的高速氣體減速的任務。因此這個環形通道又被稱為「擴散器」，空氣在這裡急遽減速的結果又會造成一波升壓，主要原理為擴散器將氣體的動能轉換為壓力的結果。這一切都走完之後，最後才將流速適中的高壓空氣從環形通道的一個出口 (或在大型壓縮機上面可能有數個對稱的出口)離開壓縮機。因此總體而言，空氣被壓縮主要發生在兩個地方，一個是在葉輪上面受離心力的作用而被壓縮，另一個是在進入環形擴散器的時候被大量削減動能而增壓。

前面提到空氣在流經葉輪時產生的反作用力是葉輪旋轉的阻力主要來源，那麼為了克服這個阻力，我們就會需要有額外的動力來提供葉輪旋轉的能量。這點很重要，但有關這一部份的動力來源暫且保留，留待後面再做解說。

渦輪膨脹器

離心渦輪其實挺有趣的，同樣的一個東西既能被用作壓縮器使用，也能拿來作為膨脹器使用。

什麼是膨脹器呢？要把空氣膨脹不是直接將高壓空氣釋放出去就好了嗎？當然所謂膨脹器的目的並不只是讓氣體膨脹而已，而是希望能夠捕捉蒐集氣體在膨脹的時候所對外做的功以為我們所用，這才是膨脹器真正的目的；否則若非如此，要讓氣體膨脹只要將高壓氣往低壓處釋放即可！其實這樣的東西我們應該是很熟悉的，比方說本系列主題一直在探討的活塞汽缸就同時既是壓縮器也是膨脹器，活塞汽缸組在膨脹行程也是擔負著捕捉燃氣膨脹降壓的過程中所釋放的功的作用。

Figure 5. 作為膨脹器使用時，氣流在葉輪內的流動方向 ^[6] ^[4]

當離心渦輪作為膨脹器使用時，一切幾乎都是一模一樣，只是方向反著來而已。高壓氣首先從原來的出口送入環形通道內，然後高壓氣從環狀通道內側的狹縫高速降壓吹出，在導流片的作用下以切線方向高速衝擊葉輪，成為推動葉輪的作用力。接著氣體順著葉輪的徑向流道流向葉輪中心，在這整個過程中同樣會產生科氏力，這個科氏力繼續提供葉輪旋轉的動力，同時讓空氣在這路程上繼續減速(切線方向)、降壓。最後已經得到一定程度膨脹的氣體從葉輪中央的出口，也就是作為壓縮器使用時的那個入口處吹出。

最終濃縮全部的結果，只要記得離心渦輪既可以作為壓縮器使用、也可以作為膨脹器使用即可，其進出口、動能、壓力等等幾乎都是互相對稱的，基本可以互相套用。

離心渦輪性能特性

不像往復式活塞那樣，離心渦輪基本只有一個主要的移動零件，而且還是平滑連續移動的(旋轉)。只要零件質量和受力分佈夠平均，幾乎可以放手用力拉高轉速，所以常見離心壓縮機能以上萬、甚至十幾二十萬 RPM 的轉速在工作；而轉速愈快，當然壓縮空氣的能力也就愈好。

這樣離心壓縮機是不是性能就沒有上限了呢？非也！離心機葉輪的轉速最終會受制於空氣音速的限制，當外緣速度達到音速的時候，就會開始遭遇超音速流場特有的震波問題，也就是所謂「音障」。白話來說就是你得付出更多倍的力氣去推動維持葉輪旋轉，但是提升的效果卻微乎其微，不合算！因此離心壓縮機的最大轉速受限於音速。觀察現實，那些尺寸(葉輪直徑)愈大的離心機其極限轉速愈低，而那些能跑幾十萬轉的離心機則都是小型的機器，符合此概念。

這裡還要補充一個可能常見的誤區。音速其實只是擺在所有關卡的最後一個大關，並不是說實際上只存在這麼一個關卡，而其實許多平價的離心壓縮機甚至可能在被音障這個關卡困擾之前，就先被前面關卡給卡住了！比如說軸承是否能夠承受如此高的轉速？該如何潤滑？特別是有些離心機很可能還是工作在高溫的環境下。又比如說在高速旋轉之下，零件的結構強固程度如何？會不會撐不住離心力就先自己爆炸了？！葉輪質量分佈是否足夠均勻？氣動外型是否足夠平均？軸心的加工與配置是否足夠精準？否則高速轉一轉可能就先把自己給轉歪變形了！還有葉輪和外殼之間照理說應該要保持某種氣密性的，可是因為兩者的相對移動速度實在太高了，類似活塞環、橡膠墊什麼的方法並不實際，因此只能留個不讓兩者接觸的縫隙在那裡 (這點可以仔細觀察 Figure 2 和 Figure 14)。這個縫隙如果能夠造的愈小，肯定漏氣就愈少、性能就愈好，但是具體能夠造得多小而不會在高速旋轉中碰在一起呢？以上這些小魔王都是基於技術上的困難，並非不能夠解決，但也確實考驗精密製造與裝配水準，以及願意投入多少成本有關。於是那些改裝過渦輪增壓組件的汽車駕駛們一定有察覺到一件事：這小小的一顆渦輪，拆開來看也好像沒什麼東西，但怎麼就賣得這麼貴啊？！

壓縮能力

既然是壓縮機，我們當然關心它的壓縮能力如何？對於這類空氣壓縮機的壓縮能力，一般看的是壓縮機入口和出口壓力的比值，並且注意這裡用的壓縮比是壓力壓縮比，而不是在從前我們可能更加熟悉的容積壓縮比！一般來說離心壓縮機的最大壓縮能力大約為 3.5 倍左右的壓縮比。當然這個數字是一個非常非常粗略的數字，並且這個數字不只是粗略大約而已，實際應用中的壓縮機也會因為不同的設計、和不同的工作狀態，而有不同的性能表現。

除了細節的設計和製造工藝之外，在根本原理上決定離心壓縮機壓縮能力的主要因素為：葉輪的半徑與轉速。大的壓縮機雖然尺寸大了好像能產生較強的離心力，但是轉速上限卻變小了；或者小的壓縮機雖然看起來好像不能產生多大的離心力，但是它卻可以容許更高的轉速上限。因此造成了一個有趣的結果：離心壓縮機不論尺寸的大小，其極限壓縮能力大約都在 3.5 倍上下！ 不論是一般常見大小的車用壓縮機、還是航模使用的超小型壓縮機、或者是像戰鬥機上面用的那種大型壓縮機，它們的最大壓縮倍率都是差不多在同一個水平。當然這裡說的是理論上限，至於實際上的壓縮比可能會更低，比方說設計和製造條件不足以至於無法轉太快、製造工藝不佳導致的漏氣和摩擦問題，或者應用時的上下游工況不匹配、或是提供壓縮動力的動力源不足等等，都會導致無法達到理論上的壓縮比。通常對於一般家用車(當然是指有增壓的款式)，其增壓比約在 1.2 ~ 1.5 左右，比較強調性能的車款才有大約 2 ~ 3 倍的壓縮比表現；當然這些只是一般常見的通常數字供參考，並非絕對。

同樣是壓縮比，但是以往我們認知的都是體積壓縮比，可是在渦輪增壓機上面的數字卻計算的是壓力壓縮比。為什麼渦輪壓縮機的壓縮比算的是壓力比，而不是像活塞汽缸一樣計算體積壓縮比呢？或者為什麼活塞汽缸標示的都是體積壓縮比，而不採用壓力壓縮比呢？

這是源自於測量的方式而導致的結果，在活塞汽缸的設計上，我們可以很方便的透過計算汽缸的幾何尺寸和活塞行程，就能得知體積對應關係；但是如果想要知道壓力關係的話，就得使用比較複雜的氣體方程式去做計算，並且不同油氣混合條件下的相關參數還是不一樣的，計算不容易也不準確。相對的對於離心壓縮機來說，流體是連續不斷的從前面進入、從後面離開壓縮機，要如何才能得知進出氣體的體積關係呢？也不是不能，但是方案複雜的多，準確性也不容易控制；反而如果要得知壓力比，就只要在進出口各放一個壓力計就可以了。

這就是為什麼兩種壓縮機會採用不同的壓縮比計算基準的原因了。而我們如果需要比較兩者的性能相關數據的話，就不要忘了對兩者的壓縮比進行一些必要的轉換計算。如果套用理想氣體和絕熱條件，則兩種壓力比的轉換關係如下：

\[ 壓力壓縮比 = 體積壓縮比^{1.4} \] \[ 體積壓縮比 = 壓力壓縮比^\frac{1}{1.4} \]

離心渦輪的優勢

3 倍多的壓縮比看似沒什麼特別之處，特別是相比於活塞汽缸結構的壓縮機動不動就能提供幾十倍壓縮的情況之下，不過離心壓縮機能在特定用途上成為最佳選擇顯然是因為具有一些特殊優點。渦輪機的優勢主要在於：體積小、幾乎無振動、以及容許的氣體通量大。這些優點使得在工作轉速範圍常保持在較高區間的航空發動機上，離心渦輪機比起像是雙螺桿式等等其它形式的壓縮機更加傑出優秀，至少你不會看到活塞形式的增壓機；否則我們可以想像一個附掛的助力設備，竟然是一個體型和結構與主要活塞發動機沒差多少的東西，那得是個什麼光景？

振動的部份好理解，只有一個葉輪在動，還是順向穩定旋轉，自然沒有像往復式活塞那樣的振動問題。至於小體積的優勢其實是其氣通量大的一體兩面，因為容許的通量大，自然不需要用上太大的壓縮機就夠了；不過這個大和小都是對比之下的結果，並不是真的拿一個超小的渦輪就可以把超大量氣體無限灌下去！當然渦輪壓縮機比起其他壓縮機也同樣存在一些問題，否則哪還有其它形式壓縮機存在的空間呢？比方說你家裡的冷氣機就不會選用離心渦輪作為壓縮機，否則你可能光在家裡看電視都能隨時聽見飛機起飛的聲音！

小渦輪與大渦輪

既然這樣，那麼大的離心渦輪和小的離心渦輪差別在哪裡呢？差別在於允許流通的氣體通量不一樣！愈大的離心渦輪可以容許更大體積的氣體在短時間內快速通過，白話說就是吞吐量大。

如果使用了不能妥善匹配氣流條件的離心渦輪，比如說在氣體流通量很大的地方卻只安裝一個很小的壓縮機，那麼就會產生兩個主要的問題。首先是大量氣體要通過一個窄口(小壓縮機的通道相較狹小)本身就會導致較大的管道阻力，情況嚴重的時候甚至能因為無法即時消化氣流，而在壓縮機前面產生迴堵並升壓。其次是在壓縮機內氣流流通速度過大時，會使葉輪的極限轉速降底，從而導致壓縮率下降。

發動機流程圖

Figure 6. 加入增壓器的發動機工作流程圖

這裡我想要介紹從另一個角度來看發動機的方法，就像是上圖(Figure 6)所示這樣。這張圖使用像是工廠流水線的方式，交代了空氣從進入發動機核心部件直到離開的處理流程，就好像工廠流水線從原料經過一道道加工步驟直到變為成品那樣；只不過這次被加工的東西是發動機的工作流體，也就是空氣。像這樣的圖片在本篇、以及計劃中的其它未來主題內都還會再出現許多次。我之所以在解說某些事情的時候喜歡使用這種表現形式的流程圖，是因為它隱藏了大量的實際結構和實現細節，讓我們可以保留專注力去注意某些真正重要的上層邏輯；人生經驗經常讓我知道，有的時候事情不要看的那麼請楚，反而可以看的更清楚！ 甚至這邏輯即使是在程式設計上面也是一樣的！

Figure 7. 比較完整交代細節的發動機工作流程圖

當然若只看這樣簡單的流程圖有時候也太簡單，如果再把本篇會關心的能量供受邏輯也一起畫上去的話，那麼這張圖應該會變成上圖(Figure 7)這樣子。其中的藍色箭頭表達空氣也就是工作流體的加工步驟和移交順序，空氣接連通過兩個壓縮工序並混合燃料。為什麼是兩個壓縮機呢？第二個壓縮機就是我們過往所熟知的汽缸，而汽缸和活塞的工作其一就是壓縮空氣；而前一個被凸顯的壓縮機就是本篇的主題，也就是發動機附掛上去的那個渦輪增壓器了。

空氣(其實可能包含混合了燃料的燃氣，為了簡化敘述以及方便解說，以下會以「空氣」簡代稱之) 經過兩道壓縮之後，接下來經過燃燒的過程，空氣在此處理工序完後會升溫升壓。高溫高壓的空氣隨後被送至膨脹處理流程，在這個工序裡空氣會減壓膨脹，然後膨脹器會捕捉氣體在過程中所做的功。至於膨脹完之後就是剩下的垃圾，也就是廢氣的排放了。

這裡還可以發現一件事，膨脹器和壓縮器其實是同一個零件，都是汽缸和活塞，但是在這被切割成是兩個不同的工作處理模組；事實上其實連燃燒器在活塞發動機裡面也都是在同一組機械結構內。這是因為這兩個步驟做的應該是兩件不同的工作，只不過剛好能用同一組零件來完成，但是事實上若不理會一些副作用的影響的話，也並不是不能真的像圖示一樣用獨立的兩個汽缸去分別完成這兩件事。這就好比是一般企業組織常見的「財務」和「出納」其實是兩個不同的工作劃分，各自負擔不同的責任，在許多大企業裡面也是由不同的職員來擔任工作，然而在很多中小型企業或組織單位裡面承擔這兩個職務的往往其實是同一個人，是一樣的道理。這個現象也表明了像這樣的流程邏輯圖更加看重的是流程和處理邏輯，而非實際的實現細節！

空氣處理流程看完之後來看看能量傳遞情況。許多的處理工作是需要消耗能量的，於是綠色的箭頭交代了這些能量的來源、和供應的方向。可以看到第二道壓縮器所使用的能量源頭就是來自於膨脹器，不過中間經過了一個飛輪來過手轉交，同時飛輪也負責將膨脹器產生的多餘動力向外輸出，成為發動機對外的功率輸出出口。那麼第一道壓縮器的驅動動力來自於哪裡呢？這當中有一些內容值得探討，不屬於本節範圍，因此在這裡就暫時先留個空白；如果不告訴你一個具體的答案會導致渾身難受的話，你可以先理解為它後面有一個搖柄需要有一個人用手去轉它！

上面這第二張流程圖(Figure 7)比較詳細些，但有點太過詳細，所以後面再用到基於該圖的衍生圖解的時候，可能會更加精減隱藏一些不需要過度被關注的內容。

增壓器的角色

理解了本篇所介紹的流程圖之後，回過來看看增壓外掛在整個活塞發動機裡面到底擔當了什麼樣的角色？

從流程圖的呈獻可以發現，增壓器和汽缸的工作就是一模一樣的，目的都是在壓縮空氣；那麼用兩個壓縮器來壓縮空氣是不是顯得好像有點疊床架屋的感覺？兩個壓縮器可以合併起來變成一個嗎？為什麼要分開成兩個呢？這想法的確可行，只是實現上會產生一些問題，這就先留給讀者自己去思考，待到下一個動力系列文章時我再來解說。

因為額外增加了一個壓縮器，發動機原始的核心組件所需要的空氣會先經過它後被壓縮過一遍，這樣當汽缸吸氣的時候，吸入的空氣就都是經過增壓後，壓力和密度都已有所提升的空氣。這讓航空飛機在空氣稀薄的高空仍然能夠維持還算足夠的發動機功率輸出，也讓地上爬的汽車和水裡游的海船可以用較小體量的發動機，爆發出原本大體量發動機才有的動力輸出。

中冷器

可能還有些讀者會發現，在前面我似乎刻意迴避了一個關於壓縮機的問題，那就是壓縮升溫的副作用。

壓縮會導致升溫，這點我在以前就解釋過 ^[1]，這也同樣是為什麼汽油發動機的壓縮上限約為 10 倍壓縮比的原因，就是因為再繼續升溫下去可能會導致油氣不預期自燃的結果。那麼我們用了兩道壓縮手續串聯，這壓縮程度肯定得超過容許上限吧？難道就沒有油氣自燃的問題嗎？加入了額外的增壓工作確實會導致油氣自燃產生爆震的問題，而對此問題的解決方法就是在中間加入一個冷卻器來給空氣降溫。

Figure 8. 加入中冷器的發動機工作流程圖

如上圖(Figure 8)所示，在兩道壓縮工序之間插入了一個冷卻器，用來給升溫的空氣進行降溫處理。多了這道手續之後，氣體的溫度降低下來，就能讓空氣俱備足夠的條件讓後面的汽缸再繼續進一步加壓。這個冷卻器的原理和外觀長相基本與過往介紹過的液冷發動機冷卻器是基本一樣的東西 ^[7] ，在有些設計上兩者甚至還被安放在一起，唯一的主要差別就是其中一個是用來冷卻發動機冷卻液，而另一個是用來冷卻從增壓器出來的熱空氣而已。為了區別兩個冷卻器，因為後者是被安插在流程邏輯的中間位置，可能因此就被大家叫作「中冷器」(Intercooler)。

其實冷卻器被安插在兩個壓縮工序中間這件事並不是很少見的設計，比如許多火力發電廠都有這種設計。以前我就曾解釋過 ^[1] ，給氣體降溫可以減少需要投入給壓縮器消耗的能量，自然可以提高總體效率，產出更多淨功餘裕。理想上最好的情況是壓縮機本身可以充份散熱，一邊壓縮一邊散熱，進行一場溫度從頭到尾都不會變化的等溫過程，然而實際情況是這種東西現實上就很難被實現出來。因此人們還是必須得處理壓縮散熱的問題，那麼應該在哪個地方安插散熱最好呢？

理論上最理想就是在開始壓縮前就先給空氣散熱降溫，但是現實上實在太過窒礙難行！畢竟溫度從來都是自然的由高溫往低溫散，一百度的東西只要放著就能散熱，一千度的東西散熱的更快；但是吸氣入口的溫度大約就是室溫 30 到 -10 度左右，要如何把它降到零下 100 度呢？那麼換個位置等壓縮工序都全部做完之後再來散熱就好做了吧？是的，此時空氣的溫度都已經升高了幾百度，確實散熱容易了，但是也失去了意義！前面壓縮機該消耗多少功都已經先消耗完了，現在才來散熱不只沒有實際意義，反而現在降下來的溫度等會到燃燒時要消耗掉更多的燃料才能夠補回來，偷雞不著還蝕把米！因此折衷下來，將散熱的工序安插在兩個壓縮器中間就是最為妥當的辦法。前面壓縮器給空氣的升溫效應使得散熱工作得以順利且有效的進行，散熱降溫的結果又能幫助下一個壓縮工序減少所需要的能量消耗；此外在汽油引擎上可能更重要的作用是降低氣體溫度，使在後面的壓縮工序裡(汽缸內的壓縮)不至提前自燃，解決因增壓導致的爆震問題，於是事情就這麼成了。

另外中冷器作為一個普通的熱交換器，它的散熱能力也是有限的，至少不可能讓散熱出來的空氣回到像吸氣的時候那樣的溫度。散熱器處理完的空氣肯定還是有點溫度的，只是不那麼熱燙罷了。那麼這就導致一個問題，對於後面的活塞汽缸來說，其吸氣時的空氣溫度肯定是比沒有前置增壓器的情況下高得多，如果還是維持以往設計的汽缸壓縮率的話，就會產生爆震問題！因此 搭載了增壓器的發動機款式，其汽缸的壓縮比一般會被設計調降，通常壓縮比會被降至 7 左右；當然這排除了那些事後才改裝上增壓器的情況！

增壓器動力來源

前面一直空白了一個問題，那就是增壓器的動力從何而來？之所以沒有立刻解說這個部份，也是因為這不僅僅只是由誰來提供動力的問題而已，而是隨著這個動力提供的來源不同，還會導致發動機整體特性有所變化，實在難以在前面「順便」兩三句就能夠交代明白！

簡單總括來說，增設的壓縮機動力來源有三：馬達驅動、曲軸驅動、與排氣驅動。

馬達驅動

首先來看電馬達驅動，這種方式最為簡單明瞭，用一顆電動馬達來驅動壓縮機運轉。好處是增壓器與發動機核心部件完全脫勾，彼此的交互影響最低；缺點就是需要額外提供電源來供應壓縮機使用。壓縮空氣本身需要消耗可觀的能量，因此雖然同為附屬裝置，可是增壓器對能量的需求與什麼泵浦什麼的設備相比那都不在一個層級。那麼這就要求採用此種方案的車輛必須俱備強有力的供電系統，可能還需要個大電池，而這並不是一般汽車或航空器能夠合理負擔的情況，因此一直以來這個方案極少被應用在實用的發動機上。不過對於近年興起的油電複合車來說，這個方案確實成了一個可被考慮搭配使用的方案，這點晚點再談。

這種方案因為目前相當罕見，也就少聽過什麼廣傳的通俗說法，因此我就暫且自己望義生字稱呼其為「電驅增壓」好了。

曲軸驅動

Figure 9. 由曲軸驅動增壓器的發動機工作流程圖

使遇曲軸(或飛輪亦同)動力來驅動增壓器是一個歷史相當悠久的成熟方案，因為從曲軸偷動力來驅動週邊裝置這件事情，大概從汽油發動機問世以來就已經存在了。各種油泵水泵、磁電機、水箱風扇、車用空調等等一直以來都大量採用曲軸的動力來驅動，雖然這會使發動機的功率輸出被偷走一部份，不過除了冷氣之外的性能減損佔比都是很低的，也就不是太重要。既然如此，那麼就給發動機曲軸多增加一個負載，用它來驅動增壓器的運轉成為一個可行且便捷的方案。這個方案是從增壓器出現在汽油發動機上面開始直到現在都被廣泛使用的最流行方案之一，也是二戰時期那些所有裝備了增壓器的戰鬥機裡面幾乎唯一的方案。

此方案的缺點就是會分走發動機輸出的動力，而且分走的可不是一星半點。以二戰時期的戰鬥機來說，增壓器在全速運轉的時候掐指一算可能就得消耗掉約 500 馬力，而整個發動機的總功率可能也就 1500 之譜，也就是大約三分之一都給小小增壓器消耗掉了！當然也如同往期的分析一樣，增加壓縮率同樣會提升發動機功率和效率，總體而言一來一回之下還是很划算的，也才使得為什麼這個方案那麼廣泛流行在各種增壓發動機上面。當然曲軸驅動模式還有一些其它的優點，不過這得與下面最後一種驅動方式進行比較才行。

對於這種驅動方案，一般流傳的通俗稱呼叫做「機械增壓」，雖然我一直對這種稱呼方式有些意見，合著其它方案難道就不是機械驅動的增壓了？其實這個通俗的名稱主要是為了區分下面即將介紹的另一種增壓驅動方案而產生的語言鏈變，其完整的形容稱呼應該是「機械驅動式渦輪增壓」；不過語言乃約定俗成，如果大眾們都習慣這麼叫，並且也都知道在表達什麼東西，那倒也不能說是什麼大錯。只不過我個人還是對此有些微詞，但是用完整的表述好像也太長，所以在本文還是就精減稱呼其為「軸驅增壓」好了。

Figure 10. Bf109 機頭側邊明顯的發動機空氣吸氣口 ^[8]

Figure 11. Bf109 所使用的 Benz DB 605 發動機，標示的位置就是配備的離心渦輪增壓器，其中央吸氣口正好對應上圖標示的吸氣口 ^[9]

Figure 12. P&W R-2800 星型發動機也配備了曲軸驅動的離心增壓渦輪，圖片上的標示位置能看到葉輪、以及與曲軸連接的變速齒輪 ^[10]

排氣驅動

Figure 13. 由排氣驅動增壓器的發動機工作流程圖

最後一種常見的方案是使用發動機的排氣來推動增壓機的作法。能利用排放的廢氣來作為推動力的條件，其實主要來自於：活塞發動機排放出去的廢氣本身仍含有相當的壓力能量未被有效攔截。這也是往期一直提過的，因為曲軸和連桿的運作特性，使得活塞不得不在還未讓氣體充份膨脹的情況下，就得將其排放出去；而這些廢氣除了直接放掉之外一直也缺乏妥善利用的方式，最多就是將排氣管往機體後面的方向彎曲，使其排氣動能能夠稍稍補貼總推力 ^[7]。現在可好了，前面就說過離心渦輪可以正反對稱使用，把它卡在排氣管上面就成了膨脹器，於是現在就可以充份捕捉原來被大量浪費掉的排氣動力了！

這個方案需要使用兩個離心渦輪，一個在前端作壓縮器使用、一個在後端作膨脹器使用，膨脹器截獲的能量就用來提供壓縮器使用。雖然從流程邏輯圖來看這兩者的合作路徑有些遙遠，不過在實際的實現上這兩個設備往往就是背貼著背的好鄰居，直接共用同一根旋轉軸，還被封裝在同一個結構內成為一個整體，如下圖(Figure 14)所示。

這種增壓驅動方案一般流傳的通俗說法叫作「渦輪增壓」，不過其實我對這種稱呼方式也很有意見就是了，合著其它的增壓都不用渦輪了？對於這種增壓方案其實有現成已經流傳的另一種更加貼近詞意的名稱為「排氣渦輪增壓」，或者簡稱為「排氣增壓」，而本文也將使用這兩種名稱來稱呼採用這種方案的增壓系統。

Figure 14. 排氣渦輪壓縮機，圖中右邊藍色部份為用來壓縮空氣的部份，而左邊紅色部份為由引擎廢氣吹動的膨脹器 ^[11]

由排氣驅動的增壓裝置最大的優點，就是不像曲軸驅動的方案那樣需要吃掉大量的發動機功率。排氣渦輪除了會增加些汽缸排氣的背壓阻力之外，幾乎就不影響發動機的運作，還能夠進一步提升發動機性能，是一個單從性能數字來看只有優點而沒有缺點的方案，而這也是它的最大優勢之所在。因為它使用的是原本被浪費掉用不到的能量來驅動，因此幾乎可以說是白嫖動力，對於功率和效率的提升都能提供相當大的幫助。

但除了帳面上性能的好處之外，排氣渦輪在現實上存在許多缺點(否則哪還有其它增壓形式存在的空間呢)。例如使用汽缸排放的廢氣來工作的渦輪膨脹器，會需要面對在高溫環境下運作的問題，如此其材料高溫耐受性、軸承耐受度、以及潤滑等相關的問題，都會增加在設計上的難度，並提高製造即使用維護的成本。除了對機油的性質要求更加嚴苛之外，如果在發動機高功率運轉過後熄火，渦輪軸承內部的機油會因為失去油泵的動力而停止流動，在配合上渦輪本身還處於高溫的狀態，就容易引發機油焦炭化並造成阻塞的問題。所以許多帶排氣渦輪的汽車款式會要求要在熄火之前先原地怠速個幾分鐘就是為此。

此外在航空飛機上的應用，排氣渦輪以及其相關的設備是比較佔用空間的 (也許是因為航空發動機的排氣量都是幾十升起跳的原因吧)。這項問題在體積本就比較龐大的轟炸機、運輸機等飛機上不是什麼大問題，它們經得起發動機尺寸的微幅膨脹，所以這類大飛機都會裝配排氣渦輪增壓設備。但是在體積本就比較小巧且機內空間侷促的單引擎戰鬥機上面來說，排氣渦輪就成了沈重的奢侈品，因此幾乎所有二戰時期的螺旋槳戰鬥機，使用的幾乎全都是由曲軸驅動的增壓設備，只有極其少數體型較大些的戰鬥機才會選用排氣增壓的方案，例如 P-38、P-47 等。

Figure 15. 著名的 B-17 轟炸機從下方就能明顯見到露在外面的增壓渦輪排氣裝置 ^[12]

Figure 16. B-17 排氣渦輪系統結構圖，雖然佔用不少發動機艙空間，但對於這麼大一架飛機來說並沒有什麼太大的影響！ ^[13]

Figure 17. 也是著名的 P-38 戰鬥機，雖是小型戰鬥機，但雙發雙身的設計也令其俱備足夠的體量和空間，可以容納排氣渦輪系統；其中綠色標註位置為中冷器的空氣進出口 ^[14]

這裡我再補充個小故事。以前小時候看到 P-47 戰鬥機的時候就一直有個疑問，覺得它的氣動力外型看起來沒啥讓人覺得亮眼之處，還又大又重，到底是怎麼就成了二戰經典名機的呢？事實上這飛機還真的就和看起來的樣子一樣，又大又重。看它的內部結構(Figure 20 和 Figure 21)就能發現，這主要歸功於為了用上排氣渦輪而加入的增壓器、熱交換器、和相關管道管路所致的結果。其操作性能也如同外觀給人的第一印象，有些笨拙，基本不是其它主流單引擎戰機的對手 (所以後來它更大的用途就成了利用自身載量大，加之皮糙肉厚能夠硬扛傷害的特點，成了極佳的對地支援飛機)。然而在上了萬米高空以上的空域，一切就不一樣了！當其它有些對手連爬到這個高度都費勁的時候，當其它裝了曲軸驅動增壓器尚能一戰的對手先被增壓器給吃了三分之一動力的時候， P-47 卻依然保有豐沛的澎湃動力，自然能夠遊刃有餘的對付其他對手，於是就這麼成了經典著名的戰鬥機！

Figure 18. 與 P-51 戰機，注意到雖然照片中的 P-47 戰機位在畫面的後方，但仍能明顯展現出其體型比別人大了好幾個尺碼！ ^[15]

Figure 19. 另外一張比較圖比較了 P-47 與其它同樣著名的單引擎戰鬥機的體型大小比較 ^[16]

Figure 20. P-47 增壓系統在其內部的排佈圖，可見其佔據了大量空間 ^[17]

Figure 21. 另一張 P-47 內部的排佈圖 ^[18]

增壓引擎特性

如果只看最佳的性能表現數據的話，加上增壓器的作用就是能夠提升一大截的發動機功率，用體量小一級的發動機產生出體量大一級才有的動力輸出而已。不過實際上遠不只如此單純，增壓器的存在會給發動機的整體產生一些在運作特性上的影響。什麼維修保養、耐用度、壓力承受強度之類的東西先撇開不談，這裡就只單純探討在性能表現及操作特性上所造成的改變。但是其實追根究底，這一切的不同和改變基本全部來自於同一件事：

渦輪機的壓縮能力，與渦輪的轉速成正比；轉速愈高，壓縮力愈強，反之亦同。

也許你會直覺上的覺得「這可不是廢話嗎？」但那只是因為現在只是單單只看渦輪本身的這條特性而已，才會顯得這件事好像簡單到沒有必要去過度深入；然而上面這條原因，以及由其所引發的一系列現象，導致改變了整個帶渦輪增壓的發動機的表現，甚至貫穿到在純渦輪的發動機上面所引發的一系列令人頭疼的問題，根本原因都是由這項看似廢話的因素所致。

非線性動力

掛了渦輪增壓的活塞發動機，其動力控制會較為偏離人的正常直覺反應，導致操作的技術難度提升。 (不過在當代因為這類發動機都是由電腦來進行實際的底層控制， 所以操作的駕駛員可能比較難親身感受到所謂的這種非線性動力反饋特性， 因為這些困難基本是體現在控制軟體的設計上面，由相關設計人員先代諸位駕駛者給感受完了。) 渦輪增壓發動機的動力反應是非線性的，這點與機車討論區裡面關於碟煞和鼓煞的討論裡能見到。

Figure 22. 油門深度與引擎出力之間的關係對應示意圖，其中藍色線段就是線性的對應關係，而紅色為帶增壓器的對應關係

先說說線性的反應是什麼呢？意思就是採了多少油門，引擎就出多少力；全踩下去就是全功率，踩一半就出一半功率踩四分之一就出四分之一功率等等，以此類推。而渦輪增壓款發動機卻可能是踩全部出全功率沒錯，但是踩一半的時候可能只有三分之一功率，而踩三分之一的時候可能只有或許五分之一的功率，如上面示意圖(Figure 22)所示。這會導致發動機在高功率區間的油門反應異常靈敏，一點點的油門差異可能導致發動機輸出的大幅度變化，有點像是你在洗澡的時候想調個合適的水溫那樣；而在低功率區間，發動機的動力響應就不太好，可能大踩大放之下發動機卻向個老賴似的反應不靈巧，這樣當你突然想要加速逃跑的時候，就會吃點苦頭！

以上這現象的原因已經先行提點過了，就是肇因於增壓器的壓縮能力浮動所造成的結果。不像是活塞汽缸，不論轉速高還是低，壓縮的倍率是一樣的(先撇除汽門正時等而只論理想之分析狀態)，而增壓器的壓縮倍率卻會隨著轉速的變化而變動。發動機對空氣的整體壓縮率，是由汽缸的壓縮率和增壓機的壓縮率乘積的結果，而增壓機的增壓值變動，就使得整體的空氣壓縮程度也是變動的。意思就是說在高轉速的時候，空氣壓縮比大，動力輸出可達設計標準；但是轉速較低時空氣壓縮比變小，動力輸出會比預期的還弱。甚至於當轉速夠低的時候，增壓器沒能夠產生什麼作用，此時壓縮基本全靠汽缸；然而我們已知汽缸的壓縮率在設計上就已經被刻意下調了，因此此時動力表現甚至就還不如沒有增壓機的發動機。此外在底轉速的區間，增壓器不只沒能幫上什麼忙，其機械結構還增加了吸氣阻力，使得整體性能表現還會更加悽慘一些！

總結而言，帶增壓器的發動機其理想的性能表現區間會體現在較高轉速的時候，而低轉速區間是性能較為潺弱的部份，甚至還不及於沒有設計增壓器的發動機。此一特性使得增壓款發動機不論是在設計上還是使用上，都會更加側重於高性能部份的表現。此外其非線性的動力控制特性會使得操作使用上更加需要技巧和熟練，不過在近代電腦控制的發展幫助下，這項特性多半被隱藏在數位控制邏輯的背後就是了。

反應遲滯

增壓式發動機還有一個討論熱度也挺高的特性，那就是反應遲緩的問題。渦輪遲滯的現象特別發生在由排氣所驅動的增壓器上面，主要的表現行為就是當操作加大油門時，發動機需要一個反應的時間才能達到所預期的動力狀態，這個反應的延遲就被稱之為遲滯。因為這個問題因為被關注的熱度相當高，所以直接搜尋相關關鍵詞如「渦輪遲滯」、「Turbo Lag」等，就可以查到很多相關的影片和討論區，我這個比較難嵌入影片的地方就不放影片了。發動機的具體響應時間在汽車上約為幾秒鐘左右，至於飛機上我就不知道了，我也沒開過這種飛機，或許有些剛好有相關經驗的讀者可以提供經驗？

遲滯產生的根本原因還是同樣的：渦輪的壓縮力隨轉速變動。因為由排氣驅動，所以首先發動機得先提高轉速，排氣強度增強後才能提供給排氣渦輪更大的能量輸入，這就直接造成渦輪的轉速提升滯後於發動機的曲軸轉速。但在排氣強度增加之後，渦輪也會因為葉輪本身的慣性因素，需要一個時間來進行提速，於是再進一步加劇其工作狀態反應滯後的程度。具體的渦輪反應滯後延遲時間與葉輪的轉動慣量成正相關，通常來說體積愈大的增壓器其滯後情況也愈嚴重。

這個渦輪遲滯的效應和前面所說的非線性輸出是不一樣的，注意別搞混了！前者指的是發動機工作狀態與控制輸入(油門)之間的反應速度，後者指的是兩者之間的數值大小對應關係；而由排氣所驅動的增壓渦輪則正好二者特性皆有！於是渦輪遲滯的因素，成為除了體積與高溫環境耐受性之外，讓許多實際應用中寧願接受軸驅增壓渦輪，也不願意選擇排氣增壓渦輪的另一項重要原因。

各種大小問題與應對方案

至此有關渦輪增壓的原理和主要特性已經介紹完畢，最後再來統整一些增壓款發動機由於增壓器的存在而常見的一些問題、現象、以及相關解決方案。當然這裡主要著重在設計上的考量，對於使用與保養等相關的部份反而不是我熟悉的領域。

多級多速

在汽車上面好像比較沒有這麼複雜，但是在看到二戰時期戰鬥機相關數據的時候，常能看到像是「一級一速」、「二級二速」、「一級二速」等等詞語，那麼這些是什麼東西呢？又是為了解決什麼樣的問題而存在呢？

如同最開頭所展示的發動機功率和高度關係圖所展示，以一般離心渦輪能夠提供的增壓幅度來看，大概只能夠讓飛機支撐到大約三千至四千公尺左右的高度，那麼那些能爬到一萬公尺以上的飛機是怎麼辦到的呢？能爬上萬米高空的飛機通常需要更高的增壓比，一般可以串聯兩個離心渦輪，這樣就能提供約 12 倍左右的汽缸前進氣增壓，而這種串聯了兩級增壓渦輪的配置就稱為「二級」增壓。

Figure 23. 二級增壓器，注意到它有兩個葉輪，能將進入的空氣分兩次接力壓縮 ^[19]

不過在軸驅渦輪系統上還有個問題。如同前面所述，一般設計渦輪增壓都是比較看重高功率時的性能表現，但是飛機得要從低速到高速都能用啊！至少飛機得能在低空以低功率條件飛行，至少要能低速起飛降落吧？那麼這就會遇到一個問題，增壓器本身需要分走發動機的曲軸動力，這在高功率運作時問題不大，但是在低功率運作下就會導致發動機負載沉重，要不就是有不容易發動、容易熄火、和油耗偏大的問題，這與汽車掛著空調壓縮機冷車啟動的情況有些相似。

對此問題，簡單的解決方法就是不要掛那麼強力的壓縮器，或者降低些壓縮器和曲軸的轉速配比，簡單來說就是靠著犧牲增壓機的性能來補救發動機在低功率工況下的運作順暢，至於缺點副作用我想就無需再多說明了。另一種解決方法就是給增壓器也配個變速齒輪，讓渦輪能夠切換與曲軸之間不同的轉速比。當然這不需要像汽車排檔那樣複雜的變速箱，一般通常增壓器的變速機構也只需要提供兩種不同的轉速就夠了，這就是所謂的「二速」，至於不能提供變速功能而只有一種轉速配比的就叫作「一速」。

Figure 24. 一個二級增壓器的葉輪傳動結構，其中給第一級葉輪配置了兩組不同齒比的齒輪組可供切換使用 ^[19]

至此就能明白所謂的幾級幾速是怎麼一回事了吧！簡單總結而言，一級增壓能使飛機爬高至約三千公尺上下的高度，而二級增壓能使飛機飛至萬米左右的高度；二速的調配能使飛機在低功率運轉情況下保有一定的實用性，更使增壓器可以在高空放開手腳賣力工作；而通常在汽車上並不會見到這些設計，因為一級一速在大多情況下已經足夠在地面上使用了。

渦輪遲滯

對於排氣驅動的增壓器而言存在油門反應遲滯的現象，這現象在飛機上可能問題不是很大，畢竟天空很寬廣，所以比較少見航空發動機對此問題有太多的著墨，至少在活塞發動機上面少被關注。但是對於在地面上行走的車輛來說，這問題常常就會讓人困擾了，而渦輪遲滯的問題也常常是汽車之所以選用軸驅增壓而捨棄排氣增壓的一項重要因素！

降低壓縮機葉輪質量

在採用排氣增壓的前提下，從根本上改善遲滯的方法就是要提高渦輪葉輪的提速和降速反應力。一項方案是減輕葉輪的質量，質量降低了則其轉動慣量自然也降低，對氣流的反應就能更加靈敏迅速。當然降低葉輪質量也會導致葉輪的結構設計受到挑戰，所以這方案除會提高對於材料的質量與強度要求，也會提高對於製造加工技術的要求。

雙渦輪並聯

另一個方案是採用體型較小的渦輪壓縮機，小型葉輪的轉動慣量小，自然能反應更快。但是前面也提過，壓縮機太小的話可能會造成無法負荷發動機的氣流流通量需求，並且引發一掛的問題。對此問題，一個簡單粗暴的方案就是：一個不夠，就安上兩個一起來唄！這就是在汽車上常見雙渦論配置的最主要原因。不同於飛機上採用雙渦輪的目的是將它們串聯起來以提供更大的增壓比，汽車上的雙渦輪往往是採用並聯的方式以提供足夠的氣通量。

Figure 25. 使用兩個較小的渦輪增壓機，各自只分擔處理一半的進氣 ^[11]

大小渦輪串聯

另一個方案同樣採用兩個增壓渦輪，不過不是相等尺寸的渦輪，而是採用一大一小的兩個渦輪。這樣小的渦輪可以對油門的高低變化提供比較良好的反應速度，而大渦輪可以顧及高功率工況時的壓縮性能。

當然大小兩個增壓渦輪並不能夠良好的保持同步運作，其效能和增壓比往往是不一致的，甚至差異頗大，因此不適合採用並聯共同供氣的組合方式，就如同不同電壓的電池不能並聯起來使用是一樣的。對於採用大小雙渦輪的情況一般只能採用串聯起來成為兩級增壓的方案，在油門變化比較劇烈的時候主要由小渦輪來承擔快速反應工況變化的作用，而在穩定大功率的工況下則主要依靠大渦輪來提供足夠的增壓效果。如同前面所述，在氣體通量大的時候，小的渦輪的增壓倍率會降低；當然只要這個渦輪不至於體積過度嬌小的話，是還不至於導致氣體堆積回堵，就只是增壓比會降低，不能夠提供如預期規格上的增壓比而已。

混合曲軸驅動方案

既然由曲軸驅動的增壓器比較沒有這麼多奇奇怪怪的問題，那麼就產生了一種由混合動力驅動增壓渦輪的方案。

這個想法的其中一項具體方案，是給發動機配備兩個增壓渦輪，一個由排氣驅動而另一個由曲軸驅動，然後將兩個增壓器串聯使用。好處是兼顧了不同轉速下的引擎反應速度，而且兩個渦輪之間的運作較具有獨立性；壞處就是使增壓相關設備結構更大，重量也更大。

另一個實現方案是由排氣和曲軸兩個動力來源來共同驅動同一個增壓渦輪，好處是重量小一些，反正在車輛用途上一般也不需要用到兩級增壓。但是兩個動力源的偶合和干擾性比較大，以相關的變速機構和匹配設計的複雜化作為代價，並不一定就是個美好的方案。

混合電力驅動方案

這個方案與前一個混合動力方案相似，只不過前一個方案是使用曲軸動力作為第二個混合動力來源，而這個方案則是使用電動馬達作為第二動力來源。

方案的實現方式挺簡單，給排氣渦輪增加一個電動馬達就基本完成了。當需要提高發動機輸出功率的時候，就第一時間先用電力驅動馬達立刻提高渦輪轉速，在排氣強度慢慢追上來的空檔暫時性的補貼動力供應，以減少渦輪遲滯效應。當然在發動機功率暫時性減小的時候，同樣可以使用電力短暫維持渦輪轉速，如果油門很快又回到原先狀態的話就不至於產生動力提升過慢的問題；當然如果變成長時間保持在較低的運轉水平下就沒有辦法繼續維持了，畢竟這只能暫時性提供原先反應不及的動力而已。

當然這方案的缺點也是非常明顯，採用這個方案的汽車或飛機，需要俱備強大的供電能力、以及大量電力的儲存設備。這項缺點直接導致了雖然這個方案看似很簡單很容易，卻數十年來都難以實現在實用的產品上，大概要直到近年油電複合式混動車的興起，才給這種電驅渦輪提供了得以實現的平臺。

不過雖然當代已經存在可以讓這個方案實現的運作平臺(油電複合車)，然而這個電驅方案仍然較少得到關注。首先是油電複合車輛多半強調的是經濟性，對增壓渦輪的依賴性倒不是那麼強烈，特別是如果要講究短時動力反應的操作情況，則多半是將電力資源直接輸出給驅動輪胎的馬達更加簡單實際有效，因此讓這項方案的具體實現直到現在仍為罕見。

蓄壓氣瓶

這方案按的基本思維邏輯與混合電驅方案一樣，只不過前者使用車輛的電力提供增壓器暫時動力，而本方案使用壓縮氣瓶來提供暫時的動力補充。

當發動機需要提升動力輸出的時候，就先將壓縮氣瓶儲存的高壓氣體釋放出來衝擊渦輪，使渦輪能夠不用等到排氣強度提升就可以先獲得加速的動力；相反的當動力輸出暫時性下降的時候，也可以使用氣瓶的壓力來暫時性維持渦輪的運轉狀態。然後在平時正常的工作條件下，再用曲軸的動力去驅動一個小型壓縮機來給氣瓶補充壓縮氣備用，整個邏輯概念就和電驅解決方案是一樣的，只不過由壓縮氣瓶來取代電池的功能而已。

這個方案的總和性能與用來解決同一個問題的幾種相關方案裡面算式綜和條件比較理想的，使用氣瓶提供暫時性動力的原理邏輯與用電提供暫時動力是一樣的，但是比起能夠提供足夠能量的電池和供電系統來說，氣瓶顯得更輕便小巧的多了；要說缺點的話就是需要搭載額外的用來給氣瓶充氣的壓縮機，並且相關方案技術比較新穎，相關副作用還沒有被發覺的特別明白。

延遲燃燒方案

對於解決排氣渦輪暫時性低轉速工作導致的遲滯問題，還有一個可能一般大眾更加熟悉的方案；不過一般人熟悉的可能並不是這個方案的名稱和具體運作內容，而是它所產生的副作用，也就是讓排氣管爆響、冒火，讓許多人可能會想要當下檢舉噪音污然的所謂「炸街」現象。

這個解決方案面對的情況比較特殊，它並不能夠在發動機提升功率的時候給予更快的反應速度，而是特別為了在暫時性降低動力輸出，並且很快會回復原有輸出水平的情況下適用的方案，比方說在過彎前減油，出彎後補油的情況下。具體實現方式，是由行車電腦分析駕駛員的油門操作行為，當電腦判斷應該是暫時性降低動力的時候，就會減少火星塞點火的頻率。減少火星塞的頻率，意思就是有的時候汽缸該點火的時候並不會讓火星塞點火 (至於具體哪次會點火、哪次不點火，則由行車電腦運算和決定)。這時沒有點火的汽缸就會做虛功，把混合氣壓縮之後又膨脹回來，什麼事都沒發生，然後就從排氣閥給排放出去了，這達到了降低輸出功率的目的。未燃燒的混合油氣進入高溫的排氣管，就會在排氣管內被高溫的環境引燃並膨脹，於是排氣渦輪仍然能夠得到足夠的氣體壓力推動而維持轉速，這樣發動機再次提速的時候，渦輪就不需要再經歷從低轉回到高轉的過程，這達到了緩解渦輪遲滯效應的目的。

看完這個方案的運作原理之後，應該就能了解為什麼有些車子會在放鬆油門的時候，從排氣管短暫冒出伴隨火光的砰、砰、砰炸響的原因了吧！此外這個方案雖然解決了反應性能上遇到的問題，但是副作用也是非常明顯的，費油、燃燒不完全、高噪音汙染、以及讓排氣管和渦輪膨脹器處於惡劣工作環境都是它所造成的結果，甚至於也發生過許多在炸街的過程中引燃致火燒車的安全性風險，其中亦不乏高價的性能跑車！

突然性減油門

在裝備了渦輪增壓器的車輛或飛機上，突然性的增加油門頂多就是發動機來不及反應而產生遲滯的現象，但是在突然性減油門的時候，就可能會導致損壞性的災害了！

當突然大幅收減油門的時候，後方活塞發動機對空氣進氣的需求突然減少，但前方壓縮機卻可能還沒從相當賣力的工作狀態中消減下來。這就造成進氣出現某種程度堵塞在汽缸前到壓縮機中間的管路中，給壓縮機帶來氣體流通的不穩定干擾，甚至如果累積了過量的壓力還可能會導致氣體反向衝破，逆向衝出壓縮機。這一下正向、一下逆向的氣體流動會給高速運轉中的壓縮機帶來相當大的氣流干擾和振動，可以明顯聽見壓縮機運轉發出異音，如同人在孝喘似的，所以又被稱為「喘振」(surge)。喘振發生時的氣體來回流動會給壓縮機葉片和軸心帶來強烈的干擾，甚至能造成變形與各種損壞情況，是個必須想辦法避免的討厭問題！

對於曲軸驅動的增壓器來說，因為壓縮機的轉速是與曲軸連動的，因此不存在曲軸轉速慢下來但壓縮機還在高轉速的情況，因此又可以知道這個問題也是排氣增壓專屬的問題！

相對於設計了多層壓縮機的噴射飛機發動機而言，在活塞引擎增壓器上解決這個問題的方法簡單粗暴許多。既然喘振發生的原因就是短時間內氣體在汽缸和壓縮機之間的管路堆積迴堵造成的，那我就在這個管路上裝設一個被動的洩壓閥，當管內壓力過大的時候就會衝開這個閥門，將過量的氣體排放出去，以避免發生喘振。例如下圖(Figure 26)是一個實際發動機的增壓器相關管路邏輯圖，其中的 Blowoff Value 就是這個洩壓閥。

Figure 26. 渦輪增壓發動機的氣流處理流程圖範例 ^[20]

轉速過高

同樣又是那句話：「渦輪增壓器的壓縮能力與轉速成正比」。這不只導致在發動機低轉速工作條件下增壓效果潺弱的問題，在高轉速，特別是需要壓榨馬力的全速模式下，壓縮效果太好也同樣會導致問題！當曲軸轉速拉高到某一個程度以上，超出了設計容許的範圍，增壓器提供的過強壓縮能力會讓後面的管路、中冷氣、汽缸等設備工作在設計範圍外的高壓條件下，如果結構承受不住的話就可能會導致損毀；或者即便後面裝置都能承受得住，過度增壓導致的氣體升溫幅度也會更容易引發爆震！

解決的方案也是同樣簡單粗暴，比照前面的方式在排氣管上裝設一個洩壓閥，這樣排氣管提供給膨脹器的氣體壓力受到限制，就能夠限制增壓器的運轉能力了。在上圖(Figure 26)的發動機增壓氣管路邏輯圖中的 Waste Gate 就是這個洩壓閥。

注水加力

作為最後的壓軸，再提一個軍武迷常能在二戰時期戰鬥機上面看到的發動機噴水設計。這種設計不論是在軸驅增壓還是排氣增壓條件下都存在。

二戰時期的多款經典戰鬥機往往都存在一種發動機「注水」的設計，也有些強調短暫爆發力的跑車型車輛也裝備了注水的機制，這種機制可以用來在短時間內提供超過額定標準的動力輸出，不論是在緊急爬升攔截、追擊敵人、或是逃命的時候都很好用；但是注水系統的工作原理是什麼呢？為什麼注水能給發動機帶來更強勁的動力呢？這裡我就來解釋這個原理。

首先還是那句話：渦輪增壓器的壓氣能力與轉速成正比。因為這個原因，當發動機在額定最高轉速之外稍微超過去試探極限的時候，就可能讓內部的氣壓超出發動機能夠承受的範圍。造成的結果可能是管道和汽缸的結構強度無法承受過大的壓力，也可能是過度壓縮的氣體導致溫度過高，會提前引燃油氣導致爆震，或者二者皆有。

對於上述的第二個問題即氣體溫度過高導致爆震的問題，如果我們能夠提供一種方法來給汽缸進行足夠強效的降溫，那麼就能夠讓轉速拉高更多，可以提供超額的馬力。而對汽缸內進行噴水的作用即是如此！

是的，這就是水注射的作用，用來給汽缸強力降溫以穩定油氣、控制爆震，這樣就能讓發動機超過額定功率輸出了。至於噴水會不會導致發動機浸水、鏽蝕等問題？通常來說並沒有什麼影響。因為在全功率輸出的工況下，汽缸內的溫度非常高，一點點的水噴進去就會直接蒸發變成水蒸氣，然後跟著排氣出去了。

在汽缸內噴水除了抑制爆震問題之外，還可以提升熱效率。如同本篇前面在解釋中冷器時所解釋過的一樣，在汽缸壓縮空氣之前對空氣進行降溫的話，可以減少汽缸壓氣所需要消耗的能量，那麼能夠輸出的淨功自然就多了(因效率增加)，也就使得能夠輸出更多的「額外動力」。換句話說，汽缸注水的作用其實就等同於一個強力的中冷器，只不過這個強力中冷器只在所攜帶的水噴完之前有效而已！因此這種能夠短暫允許提供更多動力輸出的裝置，一般都只保留在急切需要的時候才短暫啟用，比方說逃命的時候、或者追擊的時候、或者飆速超車的時候。

既然注水加力的作用時間取決於攜帶的水量，那我帶很多水在飛機上不就可以多開點加力了呢？這想法理論上正確，但實務上通常並不會裝設太大的注水加力水箱，本質上這是一個取捨平衡的問題。不論是飛機還是車輛，承載能力是有限的。你要多帶水，就表示燃料得少帶、或者武器得少掛，何況水可比油重多了，核算一下也許並不划算！也因為這種注水提供超級動力的設備也不是平常有事沒事就會開著的東西，因此在正常的設計配置下並不會攜帶過多的水在飛機上，大概就是供應合理的緊急動力時間而已。另外這個注水設備其實在實務上通常噴的也不是純水，在考量蒸發能力和吸熱效果的最佳情況下，通常是將水和甲醇以某種比例混合的液體噴入汽缸內。

1. 活塞引擎 8：功效分析之基礎原理

2. Pressure altitude

3. 增壓器

4. 由於相關圖片都是網路上找的，因此不同的圖片描述的並不是同一個渦輪壓縮機！

5. Radial turbine

6. Detailed Design and Aerodynamic Performance Analysis of a Radial-Inflow Turbine

7. 活塞引擎 3：散熱與排氣

8. Messerschmitt Bf 109

9. Daimler-Benz DB 605

10. Pratt & Whitney R-2800 Double Wasp

11. 渦輪增壓器

12. Wikipedia

13. B-17G. Equipment. Turbo-superchargers

14. Lockheed P-38 Lightning

15. Why the U.S. Air Force did not use the F-47 Thunderbolt in the Korean War

16. I knew the P-47 was big but these comparisons really make it stand out

17. P-47s don’t really have exhaust stains…

18. Republic P-47 Thunderbolt

19. Two-Stage Supercharging

20. Motoraufladung

活塞引擎 10：功率巔峰

Tue, 07 Jan 2025 00:40:12 +0800

大約在第二次世界大戰時期，飛機的性能突飛猛進，然而性能提升的幅度卻逐漸遭遇瓶頸。人們漸漸發現活塞發動機的挖掘潛力逐漸探底，難以再進一步提升功率，從而使得性能飛機的發展難以再進一步突破下去！那些相關的故事和介紹差不多都講到這裡就沒再繼續解釋下去了，只留下這種含糊其詞的敘述。然而到底為什麼呢？看起來好端端的活塞引擎怎麼就提升不了了呢？那麼本篇，我就要來解答這樣的疑問，這不只是解釋為什麼航空活塞發動機的動力提升遭遇了天花板，也是同時讓我們看看人們為了榨出活塞發動機的功率，做出了什麼樣的努力。

開始繼續深入之前，我要先為本篇的標題做出更加完整些的補充。本篇的重點放在提升發動機功率，然而這當中其實是存在很多隱含未述明的條件！比方說同樣是活塞發動機，船上的和火車上用的發動機的馬力數字相較之下都無比巨大，然而我們卻明白這樣的發動機完全無法被應用在飛機上，因為它們不管是尺寸還是重量都是嚴重超標！因此若要為本篇的主題做出更加完整的目的要求，那麼應該是：在合理可接受的成本與代價的增加幅度內，讓我們盡可能的想辦法去提升發動機的功率輸出；甚至於為了達成功率提升的目的，當功率與效率互相衝突的時候，可以適當犧牲效率。

提高功率的理論原理

\[ 發動機功率(W) = 單缸單次循環淨功(J) \cdot 汽缸數量 \cdot \frac{轉速(RPM)}{ 60 \cdot 2 } \]

回顧前篇 ^[1] 的總功率計算式，可以發現要提高總功率輸出的話，關鍵的要素就這三個：單缸單次做功能力愈大愈好、汽缸數量是愈多愈好、曲軸轉速是愈高愈好！而這三項要素其實還可以再濃縮起來，真正的核心原理其實不過就是： 找尋各種辦法使發動機能夠更快速的消耗燃料！ 對此言論，我想有些讀者可能會稍微扭歪一下脖子並感到疑惑。

再回顧更前篇 ^[2] 的內容，當我們忽略發動機內部的具體實現細節而只看它是一部黑盒子機器的時候，很多事情反而會更加明朗！發動機其實就是將燃料的化學熱能轉換成機械動力的機器，因此只有加速燃料的消耗才能夠根本性的提高其轉換成品的輸出量。當然，理論上提高能量轉換效率也能夠提高動力的輸出，因為在轉換效率更高的情況下，同樣份量的原料(燃料)投入便可以產生更多的成品(機械功)，只不過前提條件是效率的提升與功率之間不相衝突的情況下；然而實務上的經驗卻往往相反，許多提升功率的做法往往是靠著犧牲效率而來的！

轉速與功率

影響馬力的因素有那麼幾項，但首先得先來了解曲軸轉速與馬力之間的影響關聯，因為幾乎所有其它的項目都會影響到轉速，因此有必要對轉速本身的影響先建立起認知。

提高引擎曲軸轉速可以提高輸出功率這點，原理已經在前面、或更前篇的敘述裡面都解釋過了。從功率計算式的角度可以直接指出功率和轉速成正比；從功率就是做功速率的角度來看，更高的轉速意味著一段時間之內重複了更多次活塞出力的行程；從能量轉換黑盒子的角度來看，更高的轉速能夠更加快速的消耗燃料，自然能夠產出更多的機械功。

那麼一般是怎麼操作才能控制曲軸轉速增加呢？轉動中的曲軸其實和一般平移運動的物體沒什麼兩樣，只不過是轉動而已，所以當曲軸轉速穩定的時候，表示引擎承受的負載所成為的曲軸轉動阻力，正好相等於活塞出力所產生的轉動力矩。那麼要增加曲軸轉速，就是透過這兩種方式：其一為增加活塞推力，比方提高噴油量，更多的燃料可以帶來更大的燃燒增溫和增壓，活塞出力大了自然可以推動曲軸轉的更快；其二為降低負載，負載阻力低了轉速自然可以更快，一般通常的操作是降低齒輪箱的檔位、或降低螺旋槳的螺距。這就是為什麼那些開車有一定掌握程度的人都會說：降低檔位並補油門，就可以讓車子爆發更多動力，短時間可以快速提速的底層原理。 (其實降檔的操作是非常常見的，只不過現代人或許可能對此並沒有太多直接的感受， 因為在很多人的開車經驗裡只要踩更大油門就會有更多動力。 這是因為現代自動排檔車太過氾濫的原因，是因為行車電腦在背後自動幫你適時實行降檔操作了， 因此可能才導致很多沒有特別深入了解行車操作的人並不感覺升降檔的發生相當頻繁的原因。)

Figure 1. Porsche 911 GTS 馬力曲線圖 ^[3]

提高發動機的轉速可以直接提高輸出功率，但如果事情只有這麼簡單的話又怎麼會有動力天花板呢？因為活塞發動機的轉速並不能夠無限制的提高，到了極限轉速之後就很難再往上升了！裡如上圖(Figure 1)是一臺汽車發動機的馬力曲線圖，給我們展示了該款發動機在不同轉速之下的馬力與扭力分佈。其中馬力大致上隨著曲軸轉速的提高而等比提升，然而到了最後段卻加速下跌，即便曲軸轉速更快了，但功率輸出卻不升反降。在前篇 ^[4] 我提過，在轉速過高的時候，燃燒所需要的時間行程佔比增加便會導致效率降低的不利因素。不過除了燃燒時間之外其實還有更多其它的影響因素存在，我們可以把它們總括解釋為發動機轉速過高的時候會發生「上氣不接下氣的喘不過氣現象」，從而使得它無法再轉的更快，或轉速更快卻反而動力輸出是斷崖式下跌的結果。

再更仔細閱讀那張馬力曲線圖(Figure 1)，注意到這張圖的扭力曲線，扭力其實就是活塞推動曲柄後給曲軸產生的轉動力矩。注意到隨著汽缸供應的能量逐漸增加，活塞出力愈來愈大，然後在過了 5000 RPM 之後扭力開始減少，這就表示汽缸已經開始出現「喘不過氣」的現象了，因此轉速提高但扭力卻減小。可雖然扭力減少了，但是轉速增加了，扭力減少的速度還沒轉速拉的快，因此功率的輸出依然在往上增加。而汽缸喘不過氣的現象隨著轉速的不斷提高而愈來愈明顯，終於在大約 6600 RPM 之後，扭力降低的速度比轉速提升的速度還快。此時即達到這臺發動機的最大功率峰值，之後即便再繼續拉高轉速而功率卻是不升反降了。

在了解了發動機轉速、扭力、與功率之間的趨勢關係之後，就不難理解我們只要想盡辦法讓發動機的「呼吸」更順暢一些，讓發動機「喘不過氣」的極限轉速更高一些，就能夠進一步增加發動機的功率。而提高發動機「上氣不接下氣」的門檻，就是許多發動機技術的核心目的。下面來看看有哪些方法可以提高發動機轉速上限？

減少燃燒耗時

在前篇已經有探討過燃料燃燒消耗的時間會影響到每次活塞做功的效率，當轉速提高到一定程度之後就會受燃燒消耗時間產生的負面影響，導致效率能劣化到甚至只有正常時的一半。因此點火容易、燃燒速度快的汽油才被選作為 Otto 引擎的最佳燃料。 (其實氣體燃料如瓦斯的燃燒速率會更快，可是考量到能量密度的因素之後，顯然汽油具有更好的綜合特性。)

要解決這個問題，首先可以在燃燒前盡可能提高汽油與空氣的均勻混合性，因此許多發動機使用噴霧裝置配合燃料加壓泵，將汽油噴射為霧化的極細液滴與空氣混合。在使用上燃油噴射技術以前，化油器同樣是為了使燃料霧化與空氣混合的目的而存在。當燃料的燃燒速度更快，那麼發動機會「上氣不接下氣」的轉速極限就能更高，功率自然就提高了。

提前點火

在人類卯足了勁想要挑戰發動機轉速上限的情況下，燃料燃燒耗時產生的性能劣化影響就不能忽略不管。在已經設法加速燃料的燃燒速度到極致而再難縮短之後，提前點火就成了延緩燃燒耗時的劣化影響。假設汽缸內的燃料燃燒需要 X 秒，那我就在活塞到達最頂點(上死點)的 0.5X 秒前點燃油氣，這樣整個燃燒的過程就會更加集中在壓縮率最高的活塞上死點附近。這不能夠解決問題，但可以緩和問題。

「提前 X 秒」是符合理解直覺的方法，然而實際上很難去測量並精確控制活塞運動的時間狀態，因此現實上都是靠著調整凸輪軸角度的方法(點火正時)來達成提前點火的目的；概念上雖然是「提前多少時間點火」，但是實際的實現是「提前在曲軸多少角度時點火」。那麼這就導致一個問題，在不同轉速下的最佳提前角度是不一樣的！一套點火正時的調校只有在特定的轉速下才能發揮最佳效果，在其它轉速下則非最佳狀態；我們又知道點火時機如果一不小心超前太多則會變成主動產生爆震，那麼正時的調校就得採用更加保守的策略，最終導致性能提升幅度有限的結果。不過在現代電子控制技術更加先進完善的情況下，這個問題可以得到更好的緩解。

多汽門

雖然說燃料燃燒需要消耗時間這件事確實會在高轉速的時候產生效率劣化的影響，但其實導致發動機喘不過氣而無法提升轉速的因素並不只有燃燒時間這麼一項。比如進氣的時候讓油氣填滿汽缸的速度，和排氣的時候讓廢氣從汽缸排空的速度，也同樣是導致高轉速時喘不過來的因素。並且在實際的發動機設計上，進氣與排氣的瓶頸往往成為限制發動機最高轉速的主因之一！

為了使氣流更加順暢，那些曾經會導致氣體大角度彎繞的汽缸進排氣口氣道形狀被淘汰出局了。此外，增加汽門的面積大小也同是增加氣體流量的手段。不過因為耐壓等等的因素，汽門總是被做成圓形，能夠怎麼增加氣通的閘口面積呢？那麼就放兩個圓形的汽門、或者三個嘍！這就是採用多汽門方案的原理。

古時候的發動機多是一個汽缸配置兩個汽門，一個用來進氣、一個用來排氣；現代的汽油發動機則大多流行四個汽門的設計，兩個進氣、兩個排氣。當然還有一些其它汽門數量的配置，比如說五汽門(三進氣、兩排氣)的氣通效果會更好，不過結構複雜化和成本上升的代價使得這種配置比較不那麼常見就是了。

Figure 2. 發動機汽缸解剖圖，可看到每個汽缸都設置了四個汽門 ^[5]

Figure 3. 從汽缸內部拍攝的汽缸頭視角，四個汽門與中間的火星塞 ^[5]

汽門啟閉時間調整

通常來說，四行程發動機會有一整個行程，也就是曲軸半圈的路程來給汽缸進氣、或排氣，不過當曲軸轉速不斷挑戰極限的時候，「空氣進入與排出需要時間」來完成的這點就會成為必須面對的特性。為此人們會微調修正汽門的開啟和關閉時機，就好像調整點火時機那樣。

在進氣行程，活塞快速往下運動，油氣來不及即時補充進來，使汽缸內形成一個壓力比外面還低的所謂「負壓」狀態，並且進氣時的缸內壓力差也是隨著轉速的增加而愈大。這導致一個問題，如果在活塞到達下死點的時候就關閉進氣門，那麼汽缸其實並沒有吸入足量的油氣；當然整個動力行程還是能夠繼續進行，只不過能夠得到的動力就比預期的低了，至於動力降低多少得看進氣有多麼不足而定。那麼延後進氣門的關閉時機就可以緩解這個問題，讓油氣能有更多的時間填充入汽缸內。當然汽門也不能延後關閉太多，當缸內外壓力達到平衡之後如果進氣門還開著，那麼就會反向把油氣從進氣門給推出去了。

在排氣行程，讀過我往期活塞發動機系列文章的讀者一定知道，汽缸在完成膨脹做功行程之後其實還有一定份量的剩餘壓力沒有用完，也就是說在排氣行程開始的時候，缸內氣壓還是挺大的。如果曲軸轉速並不快的話這倒沒什麼問題，排氣門一開，廢氣就會衝出來了。但是我們現在要挑戰的可是轉速極限，必須考慮到排氣門可能無法讓氣體即時通過的問題，那麼這樣的話，整個排氣行程可能活塞就是在頂著排氣的壓力前進了！這下好了，原來我們只想著壓縮行程會大量消耗曲軸動力，現在連排氣行程也要消耗可觀的動力，這影響可大了，該怎麼辦呢？於是我排氣閥就早一點打開，在膨脹行程走到尾端就快要結束的時候，我就先打開排氣門，讓廢氣先開始衝出去了。這樣就可以降低排氣行程的活塞阻力，使排氣更加順暢，也減少動力消耗。當然提前排氣的時機也得恰到好處，否則太早開始排氣的話，排氣是順暢了沒錯，但膨脹行程的損失反而讓我們得不償失！

到了排氣行程的尾端，即將銜接進氣行程的時候，我可以讓排氣門再維持開啟狀態稍微久一點，同時也提前打開進氣門。這樣可以利用下一輪的進氣來將缸內剩餘空間的最後一點廢氣給推出去，甚至如果引擎的其他狀態剛好匹配的話，排氣管的週期性低壓還可以助力把下一輪的進氣給抽入缸內，達到進氣排氣互相幫助的作用。進氣幫助推出排氣，排氣幫助抽入進氣。

全部一套整理下來，可以發現無論哪個汽門，調整就是依照著「早開晚關」的方向進行的。這樣的調整會產生一些副作用，進氣門晚關會導致損失壓縮行程的壓縮率，排氣門早開會導致損失膨脹行程的膨脹率。單獨只看壓縮與膨脹這兩個行程的話，其實會造成動力和效率的損失；不過如果進排氣導致的損失更大的話，那麼汽門調整的正面幫助就大於負面損失。總體而言可以使汽缸的呼吸更加順暢，延後汽缸「喘到上氣不接下氣」的時機，極限轉速可以再往上拉高，總功率自然就能更大了。不過也與點火時機調整的情況類似，汽門該多早開啟、與該多晚關閉的最佳時間，在不同的曲軸轉速下不是一樣的。如果為了高轉速的順暢性調整汽門，那麼就會導致中低轉速下的無力並加重油耗；如果為了中低轉速做最佳調整，那麼就會導致極限轉速降低，從而降低整體能夠輸出的最大功率。

汽門不像火星塞那樣通電就能點火，而是需要足夠的力量才能頂開汽門，因此一般還是得靠凸輪軸來進行。那麼解決不同轉速區間的最佳調校設定不同的辦法，就是使用兩組不同調校設定的凸輪軸(或同一支軸上的兩組凸輪，概念是一樣的)，然後使用機械結構在不同的轉速區間切換使用不同的凸輪設定，這樣就可以顧及兩個不同轉速區間的性能表現。當然也可以如法炮製，使用更多組凸輪軸去適配更多的轉速區間，只不過要面對的就是重量、複雜性、製造與維護成本的上漲問題。現代也開始出現一些電子控制凸輪軸調整位移的解決方案，理論上可以做到無段調整最佳汽門角位置，只不過如果看的是二戰時期老飛機的話，當然就不用期望這種科技的加持了。

Figure 4. 可變氣門正時機構 ^[6]

排氣管回壓輔助抽氣

活塞引擎的排氣管，先不管裝在排氣管上面的設備如觸媒轉化器、消音器等，就單純一根排氣管的主要作用是引導廢氣到適合的位置去排放，而非讓廢氣直接從汽缸頭放出來。然而就是這樣簡單的排氣管，竟然還能夠在上面做文章呢！

Figure 5. 高速攝影機嚇的槍口風暴 ^[7]

活塞發動機的排氣並不是連續的，而是一段一段的突波式間斷性排放，這當然是因為四行程結構的運作特性所致的自然結果，只有在每次排氣門打開的時候才會突然衝出一股高壓廢氣。但是當這一波高壓衝出排氣管端口後，卻反而會形成一股低壓，這是因為氣體和一般物體同樣具有慣性的現象。當高壓氣往低壓區衝，達到理論上應該壓力平衡的時候氣體其實還停不下來而繼續在往前衝。於是這種因為氣體慣性而衝過頭的結果，就會導致原來是高壓的位置反而產生了一股低壓，而這股低壓自然就產生吸引力。這種現象其實在各種會突然產生壓力波的地方都能看到，比方在上圖(Figure 5)高速攝影機下拍攝的槍口風暴產生的氣泡，就給我們視覺化的呈現了先膨脹，再膨脹衝過頭產生低壓而收縮，然後又收縮過頭產生高壓而膨脹、再收縮、再膨脹的過程。

回到排氣管，當高壓往排氣管外面宣洩之後同樣會產生一股低壓，這股低壓會形成將排氣管內的氣體給往外拉出來的壓力，同時這股低壓波會往回傳遞直到回到汽缸頭。那麼當這股低壓沿著排氣管回到汽缸頭的時候，如果正巧遇上排氣閥門剛好打開呢？那麼這股低壓就會順勢幫助將汽缸內的廢氣抽出來。而且我們知道排氣閥門有一段時間與進氣閥門同時開啟，所以這股低壓甚至可以幫手一把將新的油氣給抽入汽缸。

這樣一套下來的結果就是在適當的巧妙設計之下，排氣的壓力回波可以被利用來幫助汽缸抽氣和吸氣，加速氣體的抽換時間、減低進排氣阻力。一般來說這樣的設計是靠調整排氣管的長度來做到的，當壓力波從汽缸頭傳到另一端再返回的時間正好對上動力行程的週期，就能因為進排氣阻力的下降而讓發動機能輸出更多的功率。不過另一方面，這種設計要能起效的條件就是壓力傳播的速度正好吻合氣閥開關的時機，意思就是只有在特定的設計轉速附近才能得到最佳的效果，至於在設計轉速之外的其它狀態則不能提供什麼幫助。此外為了讓多缸引擎的所有汽缸在設計的最佳轉速下同時處於最佳狀態，就需要不同位置的各汽缸的排氣管長度相同，於是這就形成了現在活塞發動機都會將排氣管繞成一些奇怪的形狀的原因！

Figure 6. 為了使排氣管連接至每個汽缸的長度是相等的，而進行了適當的彎繞 ^[8]

Figure 7. 為了使排氣管連接至每個汽缸的長度是相等的，而進行了適當的彎繞 ^[9]

減少活塞行程長度

活塞和汽缸之間的滑動條件也同樣成為限制曲軸轉速的瓶頸。活塞和汽缸之間(以及其它運動零件也是同樣的)其實並非直接接觸，而是有薄薄一層機油形成的油膜在中間作為阻隔和潤滑。當曲軸轉速過高的時候，這層油膜就會因為難以維持而出現缺口，使兩邊材料發生真正的摩擦，導致阻力突然升高之外，也會加速磨耗，快速減少活塞和汽缸的使用壽命。 而活塞移動、摩擦、與潤滑的問題，同樣也是限制發動機最高轉速的主因之一！

活塞因為和汽缸之間除了移動之外還有氣密的需求，因此難以使用類似滾珠軸承那樣的解決方案。為了減緩摩擦導致的問題，除了換用不同配方的機油之外，減少活塞的移動距離也是個務實的方案。當活塞的行程距離縮短，在同樣曲軸轉速下的活塞移動速度就變慢了，換句話說就是在同樣的活塞極限運動速度之下，曲軸的極限轉速可以更高。不過若只是單純的減少活塞行程的話，會導致汽缸容積下降、以及壓縮比下降的副作用，那麼為了維持同樣的容積和壓縮比，汽缸的直徑就得造的大一點，使整個汽缸看起來會更寬、更扁些。相比於我們一般印象中的「正常」汽缸形狀比例，把汽缸造的更寬更扁除了可以容許更高的曲軸轉速之外，還有一些其它好處。例如汽缸頭的面積更大，可以安排更大的氣閥，使進排氣更加順暢快速，有利高轉速運作；又比方因為活塞行程縮短，活塞連桿和曲柄的長度都減少了，有利於整體輕量化等。

Figure 8. 各種不同長徑比汽缸的運作動畫 ^[10]

既然把汽缸造的更寬更扁有這麼多好處，那麼為什麼一般的發動機不這麼造呢？顯然是因為這麼做是存在副作用的！短行程活塞的曲柄半徑縮小，也就是給曲軸施加的旋轉力臂變小了，雖然活塞面積增加了(為了維持汽缸容積和壓縮率的關係)，因此給曲柄施加的力道也變大了，一來一回之下其實扭矩沒什麼改變，但是活塞連桿以及曲柄轉軸承受的應力更大了。活塞的行程縮短，也表示對於誤差的容忍度更低，無論是零件間隙還是製造與裝配上的誤差，其中一點點的偏移都能導致最終性能表現的惡劣影響。相比於一般常見的「正常」長行程活塞汽缸配置來說，短行程的設計對於精密加工和裝配的要求更高，對於正時調校等等的難度和精度要求也同樣更加嚴苛。此外為了保持同樣的壓縮比，活塞行至上死點時在汽缸頭所形成的「燃燒室」形狀變得更加寬扁而不「方正」，給燃燒和火焰傳遞造成了更加不利的局面。相對比之下，活塞行程比例較長的設計對於各種誤差條件的容忍度是相對較高的，燃燒空間更合理、機件應力分佈更不極端，因此當研發生產等成本有所考量顧慮的時候，就會更傾向於不採用短行程設計。

諸如此類的特性使得寬扁造型的汽缸雖然可以拉高極限轉速使極限馬力增加，但是各方上漲的成本使得通常只有追求高性能的應用如跑車、賽車等才會採用此種設計。另一方面，經由前面許多影響因素的探討中我們能夠得知一件事：許多的調整調校與設計都是和轉速有關的，通常無法兼顧在各種轉速之下都能擁有最佳表現。而寬扁汽缸(低長徑比汽缸)的應用場合多半都是為了追求轉速壓榨發動機馬力，因此往往破罐子破摔，各種調校往往著重在高轉速時的最佳表現。這一套組合下來，造成了採用低長徑比汽缸配置的發動機在中低轉速表現不佳的通常現象。

不過以上其實都是基於維持汽缸容積、和維持壓縮比的前提之下的結果，然而現實上很多這些講究動力性能的發動機其實並沒有堅持這樣的前提！它們不只減少活塞衝程，還同時降低了汽缸容積或壓縮率，除了改善比較次要的燃燒室形狀問題外(因為燃燒室的形狀也可以透過改變汽缸頭的空間設計來調整改善)，可能更大的原因是考量到在高轉速條件下的汽缸溫度所致。當然這麼設計在改善避免某些問題之外，壓縮率降低的結果也導致燃油效率降低、和扭力降低的缺點；當然對於極需壓榨發動機馬力的需求下也許這是可以承受的缺點，只不過這就更加加重了一般人對於高轉速發動機扭力都會偏低的認知了！

加強單缸功率

在探究完轉速與功率的關係之後，現在讓我們將注意力放到發動機總體功率的另一大項影響因素：單一汽缸的單次做功輸出。

增加燃料量

一個非常簡單且直覺的做法就是在每次的動力循環中投放更多的燃料。增加燃料量的方法，在使用化油器引擎上就是提高進氣的燃料濃度，在燃料噴注式引擎上就是每次注入多一點燃料，總之就是提高進入汽缸內混合氣體的燃料濃度，也就是降低空燃比。一次燃燒更多的燃料可以使增溫幅度更大，增壓幅度也會更大，動力輸出自然也更大。雖然正如前篇 ^[4] 所述，降低空燃比會導致氣體的比熱和膨脹相關特性不太好，使效率降低，但是既然現在我們更想要的是動力，那麼這點效能損失就在所難免了！

然而這種簡單的做法卻也存在一個明顯的限制：汽缸內的氧氣容量決定了能夠參與氧化反應的燃料量上限！汽缸裡面一次進氣的空氣就這麼多，氧氣含量也就佔 23%，最多就是把氧氣給完全消耗完。因此汽缸一次動力行程能夠燃燒的燃料其實也是很有限的，超過了氧氣能夠氧化的多餘燃料其實並沒有作用，再多噴的燃料也只是浪費掉而已！

從理論化學角度來看，14.7 的空燃比就是燃料與氧能夠完全互相反應的上限了。不過實際上因為燃燒總是無法那麼完美，總是會有一些些燃料其實是沒能參與燃燒的，因此實務上要完全消耗氧氣的空燃比大約在 13 上下，也就是混合氣燃料佔比 7.14%。實務上如果空燃比比這個數字還低的話，發動機廠的主要目的可能是想利用燃料的蒸發來為汽缸散熱，而不是讓活塞提供更多的動力。如果說空燃比最小值是 13 的話，參考一般汽油引擎空燃比最大值約在 18 左右，那麼換算下來，其實油氣燃料佔比的調整浮動範圍也就在 5.56% ~ 7.69% 之間。所以雖然提高噴油量的想法很符合直覺，但是站在榨取動力的角度，其能夠提供的動力提升範圍著實並不多；而實務上調整空燃比的目的反而主要是為了在提高燃油效率、和降低汽缸溫度之間取得平衡的目的。

增加壓縮比

提高壓縮比可以顯著提高做功效率，自然也就提高了功率輸出。關於這原理我在前篇 ^[1] 已有進行深入探討，實務上也確實各家發動機廠，不單是汽油引擎，而是所有燒油的發動機都在卯足了勁提高壓縮率。並且現實上每當哪家廠商能夠做出壓縮率更高的發動機，其無論是動力還是效率都會高出競爭對手一截 (至於這個一截是多大一截還得看壓縮比提高了多少而定)。

然而提高壓縮比這個方法也確實存在難以跨越的障礙，以汽油發動機的角度來說，壓縮比的上限來自於汽油自燃溫度的限制。在這方向上若想要有更大幅度的突破，可能主要得依賴化學工業那方面朋友們的研發改進成果，反而發動機設計這邊沒什麼能夠插手的空間！

增加膨脹比

我們知道目前所討論的活塞引擎都有一個特性，膨脹行程的氣體在被排放出去的時候仍然具有一定程度的能量，這些能量並沒有被很好的捕捉利用就被排放掉了。那麼如果能夠在機械結構設計上發揮一點巧思來捕捉這些能量的話，不就能夠提升單缸功率了嗎？是的，這個想法沒錯，並且現代確實也存在這樣的機構能夠讓汽缸活塞捕捉更多的氣體膨脹能量；但是對於講求大功率的發動機設計來說，往往不會使用這樣的設計！

就前面解釋過的同樣原因，增加活塞膨脹的行程會導致曲軸極限轉速降低。況且在氣體膨脹的尾端其實壓力已經處於低檔了，白話來說就是推動活塞的力量有限，反而你得給它更多的時間去充份做功。綜合這麼一套弄下來，曲軸轉速快不起來，總功率反而更低了！因此現實上增加膨脹比的方案往往是為了提升燃油效率的目的，而非增加功率的目的；而在講究功率極大化的應用場合上，絕大多數時候並不會考慮增加膨脹比。

增加汽缸容量

增加汽缸容量也是個很直觀能提升功率手段。增加汽缸尺寸就能增加進氣的量，就可以直接增加汽缸每次循環的做功大小(汽缸活塞做功就是壓力乘體積的積分結果)。並且進氣的份量增加了，氧的份量也同樣增加了，就能夠噴入更多的燃料來參與燃燒增溫。

但是增加汽缸容量也有明顯的缺點，直接能導致發動機的體積和重量等比增加。體積和重量的增大，在帶來更多功率的同時也會帶來負擔，過度變大的結果不一定會更好，因此實際上得看應用場合而決定汽缸能夠造多大。比方說用在船上的柴油發動機，其體積和重量的限制都是非常寬鬆的，因此能夠打造出比人還高的汽缸，總體尺寸達幾層樓高度的巨型發動機(至於這種巨型引擎轉速大約只有數十個 RPM 的範圍)；但是放在車上、和放在飛機上的用途來說，顯然就不能這麼造了！另一方面如同前面解釋過的內容，活塞行程的長度會影響曲軸的極限轉速，因此過大的汽缸除了導致體積重量直線飆升外，同樣會帶來極限轉速降低的不利影響。此外汽缸容量增加超過一個幅度，也會導致油氣不容易均勻混合，以及大容積之下的燃燒不容易控制等問題；當然這些問題並非無解，只要給它更多的時間去完成這些事情就行……，於是曲軸的轉速就得更慢了！這樣多方面影響下來，過度增加汽缸容量除了一次可以吸入比較多空氣之外，剩下全是不利因素，對於看重功率重量(或體積)比的用途來說是得不償失的！

綜合全部因素下來，通常在特定的應用用途上其實會存在所謂的最佳汽缸容積，這個數值在各廠家的不同設計之下或有起伏，但大體上大家都大差不差的。以汽車來說單缸容積大約在 0.5 L 左右，而在飛機上單缸約在 2.5 L ~ 3 L 上下是最適合的容量大小。

Figure 9. 有數層樓高的船用大型柴油機 ^[11]

Figure 10. 大型柴油機的內部構造 ^[12]

增加進氣壓力

增加進氣壓力同樣也能增加單缸的做功輸出，並且對曲軸轉速沒有不利的影響，現實上其實是很常被使用的方案。

一般來說進氣時的空氣條件就是一般室外的大氣條件，這樣如果要提高進氣壓力的話，我們只能找個氣壓比較大的地區來開車；當然實務上我們採用的是人工製造高壓進氣的方案，也就是在汽缸進氣之前，先使用額外的壓縮機來對吸入的空氣進行壓縮，然後再送進汽缸去做剩下的事情。這種方案其實就是現在常說的「渦輪增壓」、「Supercharger」等方案，對於功率的提升那可不是一星半點，而是能夠帶來階段性的功率大幅躍升！

其實在簡化的原理上，增壓器與汽缸同樣是在做壓縮空氣的事情，也就是說增加器的作用等效於使用了一個容積更大的汽缸、和更大的壓縮比，卻沒有真正使用大汽缸帶來的體積重量飆升缺點；但是為了簡單理解核心原理概念，這裡就把增壓器的存在當作是給發動機換上了一個虛擬的大汽缸來解說。那麼使用增壓器的方案在效果上就如同前面描述過的採用更大汽缸的方案，更高的壓縮率本來就能提升能量轉換效率，這點我從前 ^[1] 有說明過；此外更大的汽缸容積等同於有更多的空氣被吸入汽缸，氧氣含量也就更大了，這樣又能夠噴入更多的燃料參與燃燒。

不過若再繼續探究下去，對於增壓器這種活塞發動機上面的「作弊外掛裝置」並不只是簡簡單單的提高進氣壓力這樣而已，其對發動機的影響實際上複雜多了，值得以獨立的一篇文章來進行探討，因此在本篇不會過度深入解釋。

增加汽缸數量

探討完在曲軸轉速與單缸做功方面下手的方案之後，現在來看看這個發動機功率公式裡的最後一項：汽缸數量。

增加汽缸數量其實是個相當實際有用的方案。回顧前面提過的各種方案會發現，絕大多數方案都存在調整幅度的限制，過度增加單一技術的效果往往會在另一個方面帶來不利局面，例如許多方案的副作用是導致曲軸轉速降低！對此，給發動機增加汽缸數量的效果等同於增加了空氣容積，卻沒有給單一汽缸增加容積所帶來的各種缺點，如曲軸轉速降低、油氣混合與燃燒控制不易等。因此就造成了一個現象，那些追求功率的發動機，不論是在車上還是在飛機上，無不卯足了勁在堆疊汽缸數量！航空用的大馬力活塞發動機幾乎都是星型佈局，主因就是汽缸數量夠多；地上跑的布加迪威龍之所以採用 W 佈局，也是因為能在合理的幾何尺寸之下塞進更多的汽缸。這些我從前也解釋過 ^[13] 。我之前還教過大家去數汽缸數量就能夠粗略猜測發動機的馬力，也是因為在差不多同時代的技術水準之下，對於單一汽缸、以及影響曲軸轉速的運氣通暢度等，能夠下手改善的幅度是差不多的，因此汽缸數量就成為影響整體功率的最主要因素；實際表現結果也許各廠牌各型號稍有好有壞，但功率基本會正比於汽缸數量。

不過汽缸數量也並不是因此可以無限增加。除了沒有增加單缸容積會導致極限轉速降低的不利因素外，增加汽缸數量同樣會導致重量等比增加的結果；增加汽缸數量同樣也會導致發動機體積上升，只不過相比於為單缸增加容積而言，汽缸數量的增加可以依靠比較合理的空間排佈來避免單一方向幾何尺寸過大的問題。此外增加汽缸的數量也會使得各種機械結構零件更加複雜化，更多的曲柄和凸輪、更多的火星塞、更複雜的進排氣管路等等，設計製造和維護的成本同樣直線上升，也同樣會導致較高的故障率。因此在綜合了體積重量、生產製造成本、維護成本、故障率、和可靠性等各項條件之後，一款實用的活塞發動機同樣存在一個模糊的汽缸數量限制，並不能夠無限的增加上去。歷史上在航空領域曾經出現過在這項屬性上最登峰造極的產品，莫過於就是 P&W 的 R-4360 (Figure 11)，採用星型四列總共 28 缸的發動機，總重 1.7 頓，排氣量 71.5 L，總功率達 4300 hp，可謂是在那個活塞發動機主宰天空的時代裡，最令人嘆為觀止的存在了！

Figure 11. P&W R-4360 發動機，採四列星型佈局，總共有 28 個汽缸 ^[14]

結論

本篇介紹了那些在汽油發動機上用來追求極致功率的手段；當然實際上可能還有更多的可用技術沒有被介紹到，那不是別的原因，單純就是筆者我所學有限而已！在這許多被人類應用的技術裡面探討完一圈之後，會發現每一項技術的效果都是很有限的，雖確實能有程度高低不等的幫助，卻也同樣具有效用天花板，並且許多的改善方案往往是與轉速發生衝突的！當然們竭盡可能最大程度的採用各種補丁措施，發動機轉速仍受到兩項因素根本性的制約：進氣排氣順暢度和阻力、以及活塞汽缸摩擦潤滑問題。甚至於當轉速過高的時候還會發生一些億想不到的問題，例如進排氣閥門因為慣性的關係來不及關上而敲到活塞等。但是繼續探究到底便不難發現，往復式活塞引擎最根本性的問題其實就出在「往復」這兩個字上。活塞引擎的基本運作特性，決定了它的各項工作不是連續穩定進行的，而是間斷性、週期性循環的。因為這樣基於根本性結構的特性，使得一旦要它賣力運作起來，就會導致留給每一個週期裡的每一項工作被壓縮的只有極其短暫的時間，此即成為了後續所延伸大量問題的根本源頭。

於是在做盡大量努力之後，增加汽缸數量竟成了除了增壓機之外最後有效提升功率的方案；然而這個方案的成本代價也並不小，在增加馬力的同時必須要等比例的增加發動機尺寸和重量 (通常人們真正追求的改善方案是能夠大幅增加功率輸出，卻只需要小幅重量體積的代價， 因此即便是等比例的負擔增加其實已經不是很划算了，特別是對於體積和重量敏感的航空器而言)。當然這種方案在有效增加功率之餘也同樣有效的增加各種複雜度和故障率，加上同比例增加的尺寸與重量，使得飛機設計師們在得到更大的推力之餘，還得惦量一下優劣利弊是否划算？！

曾經作為開啟航空新世界的魔法水晶而存在的汽油引擎，在那個仍是活塞發動機主宰的航空時代裡就這麼走進了挖掘潛力逐漸枯竭的地步，在沒有其它替代方案的情況下誕生過一些奇葩方案和工程巨獸。當然我們後世人可以偷看歷史進程，知道在後來出現了一種完全不同於以往的全新想法思路，使得突然之間在航空領域裡為活塞發動機壓榨馬力的一切努力都失去了價值，並且讓喜新厭舊的人們立刻琵琶別抱；不過，這是另一個故事了……。在航空的世界裡，以活塞汽油為主的發動機在大約二次大戰的末期來到最高峰，實用發動機的最大馬力最終也被定格在大約 4000 匹上下；若排除掉像是 R-4360 這種不尋常的例子而只考量最為普遍廣泛的情況的話，則甚至最大功率只有 2000 匹馬力左右(這個「甚至只有」當然是以現代的標準來看的)。

不過，汽油發動機的功率潛能有限這事還是看場合的，在其它許多領域裡汽油發動機顯然仍是游刃有餘。比如在陸地上，甚至於有些時候其實是動力過剩了，使人們不得不想辦法減少發動機功率以追求更高的經濟效益！

那麼下一篇，就讓我們繼續追逐活塞發動機動力高峰的話題，來談一談本篇所留下的那個空白。這個外掛的小東西可不僅僅只是大幅提升發動機功效而已，也是航空動力史上作為承先啟後繼往開來的中間重要轉折；還讓在民用領域大部份難以成為飛機駕駛員的我們一般人，能夠在地上體驗一把航空渦輪引擎的脾氣！ (^_)

活塞引擎 9：功效分析之走入現實

Sat, 21 Dec 2024 12:17:08 +0800

接續前篇 ^[1] ，在了解了活塞發動機的基本動力原理後，本篇要來探討當理論放到現實會發生什麼挑戰？以及明明理論是這樣，但為什麼實際見到的發動機卻往往沒能那樣的這些問題。這些當然都是因為存在著這樣那樣的因素，導致實際的發動機無法達成理論上美好的狀態，而在本篇，我就要來論述解釋這些的為什麼？

本篇我會一一列出讓發動機的功效之所以程度不等的低於理論條件的各項主要因素。這些因素的先後順序並不是依照其實質影響力的大小來排序的，而是依據我的解說喜好順序、加上能否被推估驗證的難易度來進行排列的。其中有些影響因素很容易從理論數學上去分析理解，有些則不容易，而有些根本很難做純理論的分析，說不定修車師傅的經驗可能會更加準確！其實對於很多實質複雜的影響因素在實務上通常是靠實驗來得出結果，但是對我來說實驗是不可能做的，實在沒有那個資源和力氣。所以對於愈排在後面的影響因素，我能夠告訴你的只有它的影響原理了，至於實際的影響效果嘛……我們就只求個理解就好了！

Figure 1. 回顧前篇的動力循環圖^[1]

Figure 2. 此圖表與 Figure 1 的數據是完全一樣的，只是縱軸顯示的比例不一樣而已！

在開始繼續討論之前，讓我們先回顧一下前篇計算出來的動力循環圖(Figure 1)，但是因為壓力是呈指數級升降的關係，這樣的圖表實在給我們的閱覽帶來困擾，於是我們將該圖表改用對數比例重新繪製成為 Figure 2。注意這兩張圖表除了縱軸比例不一樣以外，所有的數據是一樣的！也因為對數比例軸對於觀察活塞壓力的使用上比較容易被觀察，因此我們後面的所有圖表也都會使用同樣的比例表示法。

膨脹比限制

在之前的分析中，我們完全忽視實際上造不造得出這種機械結構的問題，只完全以純理論分析，讓氣體充份膨脹到底，得到最完全的做功數字。然而實際上就如同我在本篇、以及往前的數篇文章中都有提到的原因：活塞隨著曲軸曲柄的圓周運動而進行往復，上行和下行的距離是一樣的。因此在實際流通的汽油發動機上(阿金森什麼的以後再說)，壓縮比是多少，膨脹比就是多少，沒有辦法讓氣體完全膨脹做功，活塞到底了就得放它走，所以「R=1」標示的那根紅線右邊的部份，剛好就是無法被攔截利用的部份。考量此因素之後，發動機的功效就會比能夠完全膨脹的條件下降低了。

Figure 3. 回顧前篇的汽缸壓力分佈圖^[1]

Figure 4. 回顧前篇的活塞膨脹累積做功圖^[1]

好在於有兩個因素導致雖然我們沒法讓氣體完全膨脹，但是造成的功效降低並不至於太過無法接受：

如同 Figure 3 所表現的，氣體壓力最大的部份都集中在體積最小的那個範圍區間，至於到了膨脹尾端的時候，壓力已經降到相較很低的位置了，因此就算把後面的部份切掉的話影響其實也不會太巨大。並且 Figure 4 所表示的活塞膨脹行程做功圖也同樣印證了這點。
從 Figure 2 可以看出，當壓縮比愈大的時候，氣體的做功愈傾向於在「界線」的左邊釋放功率。因此我們可以儘量提升壓縮比，當壓縮比足夠高的時候，因為活塞行程限制所導致的做功浪費也會愈低。

最後我們用一張壓縮比為 9 的下圖(Figure 5)作為總結 (至於為什麼採用壓縮比 9？這個我們後面再說明)：在容許活塞無移動限制、及考量實際活塞移動限制的兩種情況下，活塞單一行程的淨功輸出分別為 1618.1132 J 和 1481.2613 J，熱效率分別為 58.36% 和 53.42%，皆損失了 8.46%。

Figure 5. 採用 9 倍壓縮比的動力循環圖(注意淡綠線是因為膨脹比受限緣故而實際無法實現的部份)

壓縮比限制

我們已經知道提高壓縮比可以非常顯著的提升發動機功率和效率，那麼為什麼我們不要死命的提高壓縮率呢？比方將空氣壓縮個數百倍之類的？

理想很美滿，現實卻很骨感！提高壓縮率確實是一個從性能面來看只有好處而沒有壞處的方案，並且現實世界中的各家發動機廠事實上也是一直在想盡辦法提高發動機的壓縮率；然而壓縮率在實務上存在難以跨越的限制，主要為兩個因素：

壓力承受度

隨著容積壓縮率的上升，氣體壓力是呈指數幅度在增加的，在我們的分析、計算、和圖表裡都再再表現出這點特性，那麼這直接帶來的挑戰就是發動機的壓力承受能力了！所以你看那壓縮率比較高的柴油發動機，為什麼它的本體總是比較厚實，也比汽油發動機更加笨重多呢？這就是原因了。一眛增加壓縮率將不得不導致引擎體重的飆升，這放在重量錙銖必較的航空器上，當帶來的效益可能抵不過增加體重所帶來的劣勢的時候，就不一定是個對的方向了。
汽油自燃

由於壓縮的過程也會導致氣體溫度上升，然而汽油是和空氣一起混合成為混合氣之後，進到汽缸裡面被壓縮處理的，那麼這就造成一個更加嚴重的問題：如果活塞還沒走到頂，如果還沒等到火星塞點火，油氣就因為高溫而自己燃燒起來了呢？這可不就是爆震嗎！在壓縮過程中油氣引燃，哎呀這可別說有多酸爽了！

其實上面的第二點，油氣的自燃溫度才是真正限制汽油發動機壓縮比上限的首要瓶頸。

汽油的自燃溫度約為 247℃ ~ 280℃ ^[2] ，也就是 520 K ~ 553 K。為什麼會有這麼大的浮動範圍呢？因為汽油不是純質，而是成份非常複雜的混合物。如果按照我們前面的理論分析結果來看，壓縮比的上限大約就是 4 倍到 4.5 倍左右了，而 4.5 倍的壓縮比正好就是早期汽油發動機的壓縮比上限。當代的汽油發動機壓縮比則提高了不少，大約在 10 倍左右，這是怎麼辦到的呢？汽油其實是組成非常複雜的混合物，不同的精煉程度、添加劑、成份配比等都會影響汽油的穩定性，從而改變它的自燃條件。如果我們可以從上述這些因素去做最大程度的改善，只要控制住汽油在火星塞主動點火之前不要自己爆燃，那麼壓縮比就可以往上提高；這就是為什麼會有 92、95、98 等等不同標號汽油種類背後的根本原因，甚至於早年時候還會在汽油裡面加入鉛化合物(現代航空汽油好像也仍是如此)來提高爆燃穩定性。

然而即便使用了各種能使汽油性質更加穩定的配方，能改善的範圍也是很有限的，因為汽油的基本化學性質仍然擺在那裡，不會出現根本性的變化！至於其它型式的發動機如柴油引擎、渦輪引擎等為什麼能夠提供更大的壓縮比呢？根本原因就在於它們的燃料是在空氣被壓縮完成後才被噴入汽缸或燃燒室內的，因此才能完全迴避這個問題；那麼那種發動機的壓縮比限制，可能更主要是來自於上述第一點的限制條件。

油氣混合氣性質變化

在前篇的理論分析都是使用空氣在汽缸裡面進行各種折騰，但是實際上的內燃機汽缸裡面裝的可不是純空氣，而是空氣與燃料液滴微粒和蒸氣共同組成的混合氣體。因此分析時如果能使用油氣、與燃燒後燃氣的氣體參數，而不是使用純空氣的氣體參數，計算的結果就會更加貼近現實。當然因為這種參數調整非常複雜瑣碎，尤其燃料大多不是純質而是複雜的混合物，所以通常在研究探討大略性能特性粗估的時候，直接使用純空氣的參數作為理論分析使用也是很常見的方式；至於與實際結果的落差這件事……別忘了還有實驗可以做！

這裡要先介紹一個名詞叫「空燃比」，就是空氣和汽油混合的油氣，其中的空氣、和汽油的質量比例。空燃比一般大約介於 8:1 到 18:1 之間，因為比例式的右邊總是 1，因此空燃比的數字常見只標示左邊的數字，畢竟比值的定義本就是左邊除以右邊，所以這麼寫也是完全符合標準用法的。一般來說如果要完全消耗掉空氣中佔比 23% 的氧氣的話，空燃比約為 14.7，換算成對計算可能更加友好的表達型式的話，那就是汽油質量佔油氣總質量的 6.37%，而後面所有的計算分析都會採用這個數字。

空氣的 $C_p$ = 1056.29 ($\frac{J}{kg·K}$)、$C_v$ = 754.49 ($\frac{J}{kg·K}$)、κ = 1.4。汽油的成份雖然複雜，但主要幾乎都是各種不同型態的碳氫化合物，所以如果完全燃燒的話，那麼最後就會都變成二氧化碳和水蒸氣；於是經過我一通計算之後 ^[3] ^[4] ，燃燒後的燃氣推估 $C_p$ = 1087.333 ($\frac{J}{kg·K}$)、$C_v$ = 792.065 ($\frac{J}{kg·K}$)、κ = 1.373。至於燃燒之前的油氣就沒有辦法這麼簡單了，因為汽油的成份實在是太不單純，實在難以簡化分析，對於這種情況一般來說做個實驗會更容易取得結果。但是如同前面講述過的同樣原因，做實驗這個方法為我實在難以實現，於是我不得不採用特性相近的純質來類比估算汽油的效果。這裡我採用辛烷(C8H18)的數值來代表汽油， $C_p$ = 1711.3 ($\frac{J}{kg·K}$)、$C_v$ = 1638.5 ($\frac{J}{kg·K}$)，按空燃比與空氣混合之後，油氣的參數估算為 $C_p$ = 1098.014 ($\frac{J}{kg·K}$)、$C_v$ = 810.804 ($\frac{J}{kg·K}$)、κ = 1.354。

另外除了氣體的 $C_p$ 和 $C_v$ 以外，因為不再是純的空氣而是混合油氣、與混合燃氣，所以氣體密度會改變，這裡簡單將汽缸內的空氣質量除以 0.9363 ( 1 - 0.0637 ) 即可。

Figure 6. 使用油氣、燃氣的氣體參數修正後的動力循環圖(淡色部份為修正前的圖形對比)

使用修正後的油氣、燃氣氣體參數套入計算，得到的結果就如上圖(Figure 6)所示(淡色部份是先前以純空氣參數計算的結果)。可以發現混合油氣的壓縮成效比起純空氣稍差，因此壓縮行程帶來的壓力增幅有了折損，此外燃氣的比熱容也比純空氣稍大，使一樣的熱量投入所產生的升溫和升壓效果同樣打了折扣。最終使得整個功效比起使用純空氣的分析結果都有所下降。修正後的淨功輸出為 1172.1981 J、效率為 42.3%，相比純空氣版本皆下降了 20.9%。

至此我們可以得到一個結論：當空氣中混合的汽油比例愈高時，混合氣的氣體參數會愈為不利。按此原則如果要提高發動機效率的話，那麼空燃比就要愈高愈好，雖然空燃比高表示加入燃燒的燃料減少，動力輸出當然也會降低，只不過能量轉換效率會提高；而這就是為什麼當代車廠研發的強調省油的一眾最新發動機款式，一個一個都在強調稀薄燃燒的原因了！

燃燒耗時

在此前的理論分析中，我們做了一個非常重要的簡化假設：假設燃燒、放熱與吸熱是在一瞬間完成；然而實際上的情況，燃燒即便再快也總是需要時間的！

可是如果要考量燃燒會花時間這件事的話，就會讓我們的計算變得更加複雜困難難解，而這也是理論分析為什麼會喜歡忽略它的原因。既然燃燒會花時間，燃燒的同時活塞也在移動，那就不會是等容加熱，不過很可能也不會是等壓加熱，那麼這樣到底要用 $C_p$ 來算呢？還是用 $C_v$ 來算呢？並且在燃燒加熱的這個時間裡活塞也同樣在做功，且這時還不是絕熱行程，那麼活塞做的功要怎麼計算呢？可現在為了能夠知道理想與現實的差距，還是必須要將燃燒時間給考慮進來。好在現在有電腦幫忙做計算，於是我將採用一個比較簡單的計算概念來進行模擬近似。 (當然如果你對於計算的原理沒什麼興趣，只想知道計算結果的話，也可以略過下面這一個區塊的說明)

Figure 7. 處理同時進行升溫與膨脹過程的計算方法示意

如上圖(Figure 7)所示即是本文在計算模擬燃燒過程的計算原理示意圖。這裡我不使用秒、豪秒這些時間單位來定義燃燒時間，而是使用「燃燒過程佔了整個壓縮行程的多少百分比」來定義燃燒時間 (之所以參考壓縮行程，主要是考量到以後會討論到膨脹行程會延長的設計， 所以採用膨脹行程定義的話會導致比例基準浮動的問題，因此改以更加穩定不動的壓縮行程長度作為參考； 但由於意義上應該是與膨脹行程相關，且至本篇為止的膨脹比與壓縮比都還是相等的， 因此以下敘述中仍以膨脹行程作為更加符合直覺的參考標的)，以上圖為例，燃燒過程就佔了整個膨脹行程的一半。當然這麼誇張的數字只是為了示意圖畫出來比較明顯的緣故，實際上當然不一定會佔比這麼誇張。

然後我把這個應該要同時加熱和膨脹的過程(也就是上圖的紅色部份) 按氣體體積切成等份的三個區段(如上圖的土色框線標示)，將總共需要加入的熱量也平分成三等份依次加入。三區段的每個區段一開頭我就瞬間加入這區段分到的熱量，所以就會看到它的壓力直線上升一段，因為這裡還是假定瞬間完成，所以依然套用等容過程計算。加熱完後就讓它繼續膨脹做功，這一部份完全比照絕熱膨脹來計算，因為這裡沒有熱量進出，因為熱量都被我假設只在區段的開頭瞬間完成。然後體積膨脹來到了下一個區段，再次定容瞬間增溫，然後再次絕熱膨脹。以此繼續計算完所有的區段，我就能夠得到溫度與壓力在每個站點的數值；然後把每個區段活塞所做的功都加起來，就是這整個過程的活塞做功了。

當然，這樣的做法看起來非常粗糙，與實際情況完全偏離，但是其實這只是因為我只分割了三個區段所造成的結果。其實只要把區段分割的足夠多、區段足夠細碎，那麼計算下來的結果就會很貼近現實了。在下面我真正的分析案例裡面，將區段分割了 200 段來計算，可以得到真正有代表性的結果；至於為什麼這裡我只分了三個區段呢？當然是因為切少一點才容易看得清楚這個算法的結構長相啊！還有另外一個問題是區塊分割的這麼多，這樣算起來不是很累嗎？還真的是這樣沒錯，我們必須的一個一個、一段一段的把數字都給算出來；不過還好我們不用自己動手動比來算這些東西了，有賴電腦的普及，這部份的工作就交給電腦來計算就好了！

這裡所使用的模擬近似計算方式，誤差在分割的區段數量足夠多的時候就會足夠小，線圖也會趨於平滑好觀察。壓力變化的曲線幅度會隨著燃燒行程佔比的變動而變化，以本示範案例來說，稍加調整測試就能找到約在 14% 附近的時候，剛好壓力線圖呈一條水平線，而此時的模擬結果與直接使用 $C_p$ 一站計算的結果非常接近(誤差非常小)；另一方面當燃燒佔比 0% 的時候，模擬結果與先前直接使用 $C_v$ 一站計算的結果幾乎相同。經過這兩個特殊條件下的計算驗證，應可以確定本文所使用的這個計算模擬方法足夠精確可靠了。

Figure 8. 幾種不同佔比的燃燒加熱過程比較(淡色部份為前面兩個按例的計算結果作為比對參考)

採用上述計算近似的方法，我計算了六種不同燃燒時間佔比的結果出來，如上圖 Figure 8 所示；其中標註的百分比表示燃燒過程佔整個膨脹行程的比例，而淡色線圖則是先前的純空氣、和混合油氣的兩個案例所計算出來的結果以作為比較。計算結果數值如下：

燃燒行程佔比	燃燒熱量(J)	做功(J)	效率
0%	2772.7618	1172.1981	42.28%
2%	2772.7618	1141.4815	41.17%
5%	2772.7618	1098.6417	39.62%
10%	2772.7618	1033.9619	37.29%
20%	2772.7618	922.2538	33.26%
40%	2772.7618	741.5028	26.74%
80%	2772.7618	467.3280	16.85%

從結果中我們可以看到，當燃燒愈不能夠快速完成的時候，跑出來的數值就愈難看。從圖形中可以看到，在燃燒佔比 14% 以前，燃燒時間稍微這麼拖一下，壓力增幅相比完美狀態就少了頂上增幅最大的那一部份。原理也很簡單，如同前面解釋壓縮的意義那裡所說一樣，燃燒加熱最好在壓力最大的時候發生；而只要燃燒會拖時間，當活塞這麼動一下，缸內體積稍微變大一點，氣壓就會掉下來很多(別忘了那圖表是對數座標比例)，這個時候你再去加熱的效果肯定就有所折扣了。而當燃燒佔比超過 14%，即便燃料仍在燃燒加熱，可是壓力卻是不斷下滑，只不過下滑的速度比較慢點而已，因為這時加熱產生的升壓速度已經比不過膨脹造成的減壓速度了，於是效率數字就愈來愈慘不忍睹！

所以燃料的燃燒時間是愈短愈好、愈快愈好，燃燒放熱的過程愈接近於瞬間完成，則效率就會愈高。從上面的模擬計算結果來看，燃燒時間佔比整個膨脹行程為 2% 的時候，效率大約下降一個百分點，那麼如果能夠控制燃燒佔比 1% 以下，基本就可以說表現結果和理想上的瞬間完成差異不大了。

這就是為什麼汽油發動機的最佳燃料是汽油的主要原因之一，因為汽油燒的快！除了燃料本身的燃燒速度之外，我們還可以用很多其它的方法儘量縮短燃燒時間，比如說用技術能力所及的最細噴霧裝置去霧化燃料，並且設計更加有效的進氣流道，將活塞頂依照空氣動力學效果挖出一些神奇的凹槽，讓進入的氣體可以左轉三圈右轉三圈，儘量與燃料充份混合，甚至巴不得讓燃料完全蒸發更好！

提前點火也是非常廣泛的用於消緩燃燒消耗時間的應對方法。在此之前我們之所以一直都說火星塞在活塞達到最頂點的時候點火，那是基於燃燒能夠「瞬間」完成的理想前提。但是既然實際上燃燒需要一些時間，那麼實務上我能不能提前，在活塞快到頂但還沒到的時候就點火呢？答案是可以的！在絕佳的提前點火時機把握之下，當活塞真正達到頂點的時候，就會剛好是燃燒最劇烈，放熱反應最大的時候；注意這並不能夠解決燃料燃燒需要時間所帶來的上述問題，只是儘量減少燃燒耗時產生的負面影響而做的補償手段而已。因此這種調校方案有一定程度的效果限制，甚至過於激進的調整調較也會造成風險！提前點火時機的掌控和很多因素都有關係，比方曲軸轉速、進氣溫度、空氣溼度、噴油量多寡等等等等，太過於「剛好」的調校，很容易會導致稍微一個風吹草動，就變成主動製造爆震的結果！

Figure 9. 這是一個正在被使用工具檢測中的活塞，注意到它的頂不不是簡單的平面，而是呈現出一種奇異的形狀 ^[5]

最後還有一個問題，大家用的都是一樣的汽油，化學性質相同，燃燒時間雖然會因為機構設計調較而有所增減，但基礎時間應該都不會差太多。那麼是什麼東西真正造成燃燒的時間能夠佔比膨脹行程的大幅度變化，從個位數百分比到幾十百分比這種幅度呢？其實會讓燃燒佔膨脹行程的比例大幅度波動的最大影響因素，就是曲軸轉速！假設曲軸轉速 3000 RPM (這是大多二戰時期航空發動機的最高轉速範圍)，那麼曲軸轉一圈就是 20 豪秒，一個活塞行程就是 10 豪秒，那麼如果汽油燃燒完全需要 1 豪秒的話，燃燒就是佔了膨脹行程的 10%。如果轉速再繼續上升，那麼效率就會一直下降，活塞做功輸出也會愈來愈降低，這就是為什麼那些發動機馬力圖表在過了額定最佳轉速之後，馬力曲線都會往下掉下去的根本原因！

那麼既然如此，我們能不能反其道而行，降低發動機轉速是不是就可以讓燃燒過程幾乎等同於理想的瞬間完成，從而提升效率呢？答案是當然可以的！同樣以上面的情況為例，當轉速下降至 500 RPM，活塞一個行程的時間就是 60 毫秒，這樣同樣花 1 毫秒燃燒汽油，燃燒佔比膨脹行程就從 10% 變成 1.67%，情況馬上就好轉了！只不過結果也很明顯，這麼做的代價就是得犧牲發動機功率數值，也就是馬力了；這就是為什麼那些更加講究效率的發動機轉速都不高、馬力也不高的其中一項重要原因！

燃燒不完全

理想的情況下，投入的燃料當然會完全燃燒，與空氣中的氧發生反應。但是如同前面所述的同樣原因，因為在每次循環中留給燃燒的時間實在非常匆促，除了已經解釋過的燃燒本身需要時間進行以外，實際上依據工況的不同，會發生或多或少的部份燃料其實並沒有來得及發生氧化反應，也就是會發生燃料不完全燃燒的情況。不完全燃燒除了環保上的問題之外，對於效率來說也是個不利的事情，畢竟投入的燃料有一部份並沒有釋放化學熱能來參與做功就被排掉，產生了無效的燃料消耗。

在燃燒前盡可能讓汽油徹底霧化、蒸發，以及設計流暢的進氣流場，使油氣能在最短的時間內充份混合，這兩種做法基本算是完全正向的解決方案了。除此之外，解決或改善燃燒不完全的問題還有幾個方法，但是都帶有些副作用，正所謂有一好就沒兩好，實際的採用方案還需要設計者去做斟酌妥協。比如提高空燃比，也就是降低燃料量，這樣在空氣中氧比燃料多的情況下，自然更容易完全燃燒燃料，當然副作用會導致功輸出降低、發動機功率降低。降低發動機轉速也是個方法，畢竟當每個行程的時間長度足夠長的時候，也就更有時間去讓燃料完成燃燒，而此方法的副作用當然也是會導致功率降低。

汽缸散熱

我們知道汽缸處在不斷反覆燃燒的環境下，為了排出不斷累積的熱量以防止活塞汽缸被燒毀，我們給發動機設計了散熱機制，這個在我過往的文章 ^[6] 裡面有講述過。但是這個散熱的行為其實會影響發動機的工作循環，使得它不能完全符合我們在理論分析中所假設的絕熱條件。往細了探究的話，汽缸散熱這件事情在壓縮行程存在正面幫助，可以降低氣體壓縮所需要的功；但是在膨脹行程就會偷掉氣體內能，產生負面影響，同樣在燃燒過程也是；至於進氣和排氣行程則基本沒有差別。

不過實務上因為汽油引擎的工作轉速夠高，單一行程的時間很短暫，能被帶走的熱量非常有限，因此散熱現象對於單一循環來說造成的影響只能說是確實存在，但影響差異微小，基本還是與絕熱條件非常相近。汽缸散熱條件其實真正最大的影響是對於燃燒的部份。因為汽缸內壁面的溫度相較於火焰溫度可以算是冰冷低溫了(粗估大約 200℃)，那麼燃燒火焰在傳遞到接近汽缸壁時，火焰就更難繼續延續傳遞，也就是說愈靠近汽缸壁表面的油氣其實愈不容易參與燃燒發生氧化反應；至於導致的影響，請參閱前一項「燃燒不完全」的內容。

那麼這問題能夠怎麼解決呢？說實在的實務上實在很難！理論上我們應該在燃燒和膨脹行程停止汽缸散熱，然後在其它過程繼續散熱；理想上這樣能把問題解決的非常徹底，但是，這樣的發動機究竟要怎樣造出來呢？也許是近代新式汽油發動機設計的進氣對流設計加上缸內燃油直噴機制，可以讓油氣集中在中間區域的作法可以比較好的緩解掉這個問題吧；雖然說它們這些機制主要是為了稀薄燃燒的目的，對於汽缸壁溫度的影響只算是副作用而已！

進氣與排氣阻力

Figure 10. 常見的熱效率 P-V 分析圖，其中狀態 0 和狀態 1 之間即為進氣與排氣的行程 ^[7]

不知道讀者有沒有發現，在純理論的分析中，一般都完全忽略進氣與排氣這件事？其實就算少部份有把進排氣行程給畫出來的分析(例如上圖 Figure 10)，基本也都是意思意思一下而已，因為進氣與排氣時的閥門都是打開的，汽缸內外壓是一樣的，所以不會有任何機械功的產生或吸收。

然而理想的假設其實忽略了活塞快速移動時，氣體會因為來不及即時通過氣閥進出而產生壓力差的現象。如果考量到氣體進出充填與排放的流通性，那麼汽缸在進氣時其實內部的壓力會比外部還來得低(俗稱「負壓」)，也就是說其實進氣的時候活塞是需要做功的；排氣時亦然，汽缸內壓力會比外部來得高，活塞排氣同樣需要做功。具體進氣排氣的內外壓力差大小與氣閥通量、以及活塞移動的速度有關，也就是說發動機轉速愈快時在進排氣上產生的損耗愈大，並且這現象並不是在挑戰極限轉速時才會發生，而是在一般運作轉速下就會存在的影響。

氣體進出流通阻力給發動機的功效具體影響到底多大呢？我這裡實在很難去給出個分析結果，不過依據經驗人士的透路，進排氣造成的損耗其實挺大的，甚至於是給活塞發動機造成極限轉速上限的主要原因。對比市場現狀的結果來看也同樣符合描述，怎麼說呢？看看市面上那些發動機，一旦有廠家造出了新技術去讓進排氣更加順暢些，往往馬力就能得到飛躍性的提升！ (其實如果要從理論上嚴格來說的話，這些技術並不能夠提升原來沒有的功率， 只不過是把原本在理論分析上應該要存在，卻被損耗掉的功率給找回來而已。)

Figure 11. 汽缸頭的閥門和進氣與排氣管特寫 ^[8]

機件摩擦

如同小學生都知道的一樣，由各種運動零件組成的汽油發動機本身就會產生各種機件摩擦阻力，消耗掉發動機的輸出功並轉化成些許廢熱。發動機內所有的運動零件都會產生阻力並偷走發動機的動力，連桿、曲軸、軸承，還有凸輪軸、分電盤等，雖然它們的消耗相比於其它大頭而言真的影響幅度有限，但是影響卻仍然存在。其中特別值得注意的是活塞環，這個零件是為了使汽缸和活塞之間能夠進行移動的同時保持氣密而存在，但是它所產生的摩擦阻力卻也足夠可觀。依據經驗人士的透露，活塞環所產生的阻力，大概可以佔到發動機內所有機械零件阻力加總的 40%。

Figure 12. 在活塞外圍的兩個活塞環特寫 ^[9]

附屬設備抽稅

除了前述那些真正純純是「消耗」的各項要素在拉低發動機的功率和效率之外，還有一些動力是被發動機的周邊設備給吃掉的。這些設備分走了部份動力是拿去做重要的事情的，並不是純粹的消耗，並且每一項設備所提供的服務都是一個實用發動機能夠維繫運轉所必須的服務。比方機油泵提供機油循環流動的動力，冷卻液循環泵提供冷卻液體穿梭於引擎內部、及往返發動機與散熱器之間的動力，磁電機提供火星塞點火所需要的高壓電流等。這些小設備消耗的發動機功率著實並不多，算是零頭吧，但是確實分走了發動機的功率，使得可以輸出給主要任務的功率小幅降低。

總結

在本篇的分析中，考量了更多實際現實與理論完美之間的差異要素。在能夠估量的分析數據中，發動機效率從前篇基於完全理想的 58.4% (9 倍壓縮比)不斷下調，因為活塞行程導致膨脹比受限而降為 53.4%，又因油氣混合因素而下降為 42.3%，再因燃燒時間的因素而合理下調至 41.2% ~ 37.3%，甚至在較為極端的條件下可以降低至 16.9% 之普。而以上僅僅只是那些比較能夠進行分析估算的部份而已，還有一些其它難以估計的影響因素進一步消耗發動機功率，並使能量轉化效率再度下降到更低的範圍。後面這個部份筆者我實在難以計算分析給你看，只能引用一般流傳的數字，汽油活塞發動機的總體熱效率約在 30% 上下 ^[10] 。

本篇所講述的內容比較多瑣碎細節，相比起前篇的純理論分析，更多的部份是基於現實的妥協與限制。講述這些內容的用意並不是刻意要來貶低汽油發動機，而是因為在完全純理論的理想條件下，很難讓我們去理解在真實機器上的那些困難和限制。在缺乏這些背景知識的前提之下，我很難去講解航空發動機的接續發展，也很難讓我們明白不同發動機的實現之間造成性能落差的原因。

那麼在這些知識基礎的鋪墊之後，從下一篇開始，就讓我們繼續看看，那些人們在汽油活塞發動機上曾經做過的努力，各種奇思妙想背後的原理與困境⋯⋯

活塞引擎 8：功效分析之基礎原理

Sat, 14 Dec 2024 10:26:52 +0800

本篇要從比較理論的方式，從物理化學的角度去計算活塞發動機的做功和效率，目的是為了讓讀者可以從基礎科學的視角去完全明白活塞發動機運作原理的本源。

雖然整個活塞引擎的結構看上去挺複雜，然而將它們一一拆解分類之後，從原理概念上來看卻沒有那麼複雜。那些動來動去、彎來拐去的機械結構，比如鏈條、汽門、凸輪軸、油泵等等等等，其實它們的作用只是為了服務引擎使能正常運作，甚至是曲軸、連桿這些大零件也只是用來傳遞動力、改變作用力方向等作用。這些那些的複雜零件在運作的過程雖然會消耗掉發動機的功率，但是首先它們大部份效率都非常高，總共吃掉的功率雖不至於小到能夠被完全忽略，卻也沒有大到值得過度關注。並且它們只消耗功率而並不產生功率，將它們仔細推敲設計到極致確實也是各廠商努力在做的事情，但是基於前述原因，提升這些零配件的效能最終為引擎整體帶來的性能提升非常非常有限。這就好比有一句投資理財的名言：「你沒辦法靠著節儉成為大富翁，要帶來階級式的跨越必須得從開源著手！」 (這句話本身隱藏了更多投資理財上的限制條件和但書，還好在討論發動機的情況下我們可以完全忽略它！)

這樣說起來，那麼引擎上的什麼地方才是真正能量與功率的主要產出地，左右整體性能的關鍵之所在呢？那就是汽缸、活塞、與氣體了。真正決定一款發動機主要性能數據的絕對重量級影響力，都是發生在汽缸裡面的一切。掌握了在汽缸裡面發生的事情，才能夠從源頭抓住一顆引擎的核心性能。這就是為什麼那些講理論的學者在上課的時候，基本只盯著一個汽缸裡面所發生的事情在研究分析的原因了。因此本篇的所有內容也同樣如此，我們聚精會神，目光鎖定在汽缸裡面所發生的一切：進氣、壓縮、燃燒、膨脹。

另外補充一點，我們只需要考慮一個汽缸就可以了，因為多缸引擎的配置就是把單缸的結論乘以 N 而已，剩下的就是機械設計與系統佈置的細節了。

認識氣體特性

Figure 1. 將無限彈性氣球內的氣體加熱 → 溫度上升、體積膨脹，但壓力不變

Figure 2. 將無限強化鋼桶內的氣體加熱 → 溫度上升、壓力上升，但體積不變

首先我們得先來學習一些氣體的基本物理特性。對於氣體，不論是空氣、水氣、還是混合了汽油的油氣、或是其它什麼氣體，它們的三個狀態數值是我們所關注的重點，那就是：體積、壓力、與溫度。所有使用燃燒的熱量來玩空氣的引擎，都是在將氣體的這三個狀態玩來玩去而已。

如上圖所表現的情況一樣，很符合我們在日常生活中對於氣體的直覺理解。當我們對一團氣體進行加熱，那麼它的溫度就會上升(好像是廢話)，此外連帶的它的體積和壓力也都會有同步增加的趨勢。以 Figure 1 為例，我們將氣體裝在一個大氣球裡面加熱。不用擔心這個氣球會不會破掉還是融化的問題，因為這氣球是用亞德曼橡膠製成的無限彈性氣球，所以氣球內被加熱的氣體可以無限制的膨脹變大。那麼在此條件之下，氣體的壓力就維持不變，只有體積和溫度會往上升高，這就是熱力學理論中的「等壓過程」。另一種情況則是像 Figure 2 那樣，將氣體放在一個硬桶子裡面進行加熱。不用擔心這個桶子會不會爆炸、變形的問題，因為這桶子是用鋼彈尼姆合金製成的。那麼在此條件之下，氣體的體積就維持不變，只有壓力和溫度會往上升高，這就是熱力學理論中的「等容過程」。

為什麼叫作等壓過程或等容過程，而不是叫作等壓加熱或等容加熱呢？因為這些氣體的特性是對稱的，並不是只有在加熱過程中才是如此，在降溫過程中同樣如此。比如我們將上圖的東西放進大冰箱裡面降溫，則大氣球內的氣體溫度會降低，同時氣球也會愈來愈小，因為氣球裡面的氣體體積在不斷縮小，不過從頭到尾氣球內的氣壓都沒有變化就是了。同樣的，鋼桶內的氣體溫度也會降低，可是因為鋼桶的形狀不變，所以氣體體積從頭到尾都是一樣的，只是氣壓下降了。這時如果你將已經足夠冷卻降溫的鋼桶蓋子給打開，外面的空氣就會因為桶內的低壓而颼的一聲被吸進去。

以上我們是透過人工控制氣體溫度，然後觀察它的體積和壓力邊化，都還算符合一般生活直覺。然而溫度、壓力、體積這三者的變化其實是互相都能影響彼此的，比方說我可以施力給氣體增加壓力，那麼氣體的溫度會上升、體積會縮小。體積縮小還算符合一般人的直覺，畢竟我給它加壓了嘛，但是氣體會隨著增壓而升溫的部份可能就不在所有人都有經驗過的直覺裡了，但是它的溫度確實真的會上升。其實若有仔細觀察生活經驗也並不是完全不能發現這些氣體行為。比方有操作過手動打氣桶給東西打氣的讀者，可能會發現每當打氣完成後，打氣桶的下端都會溫溫熱熱的，只不過可能分不清楚到底是因為活塞和汽缸接觸摩擦所生的熱，還是由於壓縮了空氣所生的熱而已。

但是另外一種生活經驗肯定可以從相反的方向應證氣體溫度隨壓力變化的事實。當我們操作任何的手持式噴霧罐操作時，不論是用來清潔灰塵的壓縮空氣噴罐、殺蟲劑噴罐、還是玩具瓦斯槍的瓦斯噴罐等等，當我們持續一段時間連續操作噴霧後，一定能明顯感受到罐子會變得冰冰涼涼的，而這就是氣體因為持續膨脹減壓而連帶造成的溫度下降現象。

理想氣體方程

以上都是對於氣體特性基於定性的講解，而如果想要知道這些氣體特徵具體變化的量，就不得不接觸一些數學公式了。於是本節要來介紹一些氣體方程式。

首先介紹的是萬用的理想氣體方程式，它的好處是比起後面介紹的幾個方程式，這個理想氣體方程幾乎是在什麼過程下下都能適用：

\[ P V = n R T \]

其中：
P 為壓力，單位為 Pa，即 $ \frac{N}{M^2} $；
V 為體積，單位為 $ M^3 $；
T 為溫度，單位為 K，就是一般攝氏溫度加上 273.15 就是了；
R 為理想氣體常數，是一個固定的數字(8.3144626)；
n 為氣體的分子的數量，單位為莫耳。

上面出現了一些可能比較難以理解的東西，比如分子莫耳數等，但是其實這些東西在我們的應用中會被化簡掉，所以其實不理解也不重要，而且我也不想去解釋它，所以如果看不懂其實也沒關係。

上面這個理想氣體方程式在本篇中是被用來計算固定的一團氣體在兩個不同狀態下的變化關係。比方說我們把一團空氣從狀態 1，給它加熱、加壓、或壓縮、膨脹、還是散熱降溫等等，不管，反正最後這團空氣變成了狀態 2。那麼這兩個狀態下的空氣同樣都滿足上面的理想氣體方程式，也就是：

\[ P_1 V_1 = n R T_1 \] \[ P_2 V_2 = n R T_2 \] \[ \frac{ P_1 V_1 }{T_1} = n R = \frac{ P_2 V_2 }{T_2} \] \[ \frac{ P_1 V_1 }{T_1} = \frac{ P_2 V_2 }{T_2} \]

我們就用前面的氣球和鋼桶的例子來練習一下，假設初始狀態也就是狀態 1，是一般情況下的室內空氣。那麼我們取用 1000 公升的空氣來做範例實驗，也就是說：

\[ P_1 = 101325 Pa \] \[ V_1 = 1000 L = 1 M^3 \] \[ T_1 = 26.85 ℃ = 300 K \]

然後我們將空氣加熱到比方說 600 K，也就是 $ T_2 = 600 K $，那麼：氣球的那個實驗因為壓力不變，所以 $ P_2 = P_1 $，那 $V_2$ 就會變成 $ 2 M^3 $；而在鋼桶實驗下因為體積不變，所以 $ V_2 = V_1 $，那 $P_2$ 就會變成 202650 Pa。

比熱容

我們將氣體加熱會導致氣體升溫，但是給了多少熱量會導致氣體溫度上升幾度呢？這個問題在我們的發動機分析中頗為重要，畢竟當我們需要計算效率的時候，就會需要知道我們到底丟了多少熱量進去？於是本節要介紹一個重要的物體特性參數：比熱容(Specific Heat Capacity)，一般簡寫為 C。

\[ Q = C M \Delta T \]

其中：
M 為物體質量；
C 為比熱容；
$ \Delta T $ 為物體升溫或降溫的前後溫度差；
Q 為總共吸收或釋放的熱量。

比方說水的比熱容為 4200 ($ \frac{J}{kg·K}$)，意義就是如果我要將 1 公斤的水(液態)升溫 1 度的話，會需要將 4200 焦耳的熱量丟進水裡；反過來說也是一樣的，我丟入了 4200 焦耳的熱量可以讓 1 公斤的水上升溫度 1 度，或者讓 2 公斤的水上升溫度 0.5 度；當然再反過來理解同樣通用，如果 2 公斤的水溫度下降了 1 度，表示水放出了 8400 焦耳的熱量到外面。

此外一點需要注意，以上的條件只有在水為液態的時候才成立；如果讀者您自己在家裡做實驗把它加熱太多到汽化了，那麼汽化之後的反應就要比照下面描述的氣體計算法去做處理，而且還需要多考慮一個汽化熱的問題。

氣體比熱容

以上這個簡單的比熱容計算只能用在像是液體、固體類的東西上。但是氣體不一樣，氣體能膨脹，而偏偏在不同膨脹狀況下的氣體的比熱容是不一樣的！因此對於氣體，比熱容的原理和用法是一樣的，但是會分成兩個參數，比較複雜一點。不像固體或液體只有一個比熱容 C，氣體的比熱容分為 $C_p$ 和 $C_v$ 兩個數字，以空氣為例，空氣的 $ C_p = 1056.29 (\frac{J}{kg·K}) $、$ C_v = 754.49 (\frac{J}{kg·K}) $，要依據加熱或減熱的過程套用其中一個數字。比如前面的鋼桶加熱過程就屬於定容的加熱，所以要使用 $C_v$ (754.49) 來計算；而前面的氣球加熱過程就屬於定壓的加熱，要使用 $C_p$ (1056.29) 來計算。

我們發現空氣定壓加熱比定容加熱所需要的熱量多了不少，這是由於氣體會膨脹導致的。在定壓的條件下，當我們給氣體加熱時，氣體一定會因為受熱而升壓，那麼為了要維持氣體的壓力不變，就得讓氣體膨脹 (氣體增溫以後，要不就升壓，要不就膨脹，或者二者皆有之)。而根據前面我們所學過的氣體狀態特性，氣體膨脹時會產生降溫的趨勢，和我們加給它熱量導致的升溫趨勢正好互相對抗。因此最終的結果就是，在定壓條件下，當我們給氣體投入熱量時，能夠使之產生溫度的增加量較少，至少相比於同樣氣體在定容條件下是少了不少；或者也可以說，當我們要給氣體增加同樣的溫度時，定壓條件下將會需要更多的熱量，而定容條件下所需要的熱量就少得多。

回到我們的活塞引擎分析，雖然在燃燒過程中活塞仍處在運動狀態，理論上是壓力和容積同時在變化，但是在理論分析的時候我們不會考慮的這麼複雜。由於汽油油氣的燃燒速度非常快，因此我們會假設油氣在活塞達到頂點的時候瞬間燃燒完成，所以採用的是定容加熱條件，使用 $C_v$ 去做計算。另外在此偷偷先告訴你，在渦輪引擎分析中，燃燒是在定壓條件下完成的，所以會套用 $C_p$ 做計算。

絕熱指數

前面解釋過為什麼氣體的 $C_p$ 比 $C_v$ 還要大的原因，其實從物理動力能量的角度來解釋也是同樣說得通的。事實上氣體在膨脹的同時也是在對外界做功的，即便它做的功沒有被我們攔截下來並加以利用(比方說氣球的膨脹)，然而它確實是對外做了功。因此相比於定容加熱的情況，當我們在定壓條件下對氣體加熱時，其實我們所投入的熱量當中有一部份是被氣體拿去膨脹做功了，因此氣體增加溫度的幅度自然較低 (氣體的溫度反應的是氣體自身的內能)。

每一種氣體都有自己的 $C_p$ 和 $C_v$ 值 ^[1] ，而我們前面說過該二值之所以存在差異主要是因為膨脹的因素所導致。如果一種氣體特別容易產生膨脹和壓縮現象，那麼可知這種氣體自身的 $C_p$ 和 $C_v$ 差距就會愈大。因此 $C_p$、$C_v$ 差異愈大的氣體愈會具有明顯的膨脹與壓縮效應，相反的該二值差距愈小的氣體則膨脹壓縮效應愈不明顯；如果二值相等則表示該物質沒有膨脹壓縮效應，基本上這種東西就不能夠被稱為是氣體了！因為同一氣體兩種比熱容的差異正好反應出氣體的膨脹壓縮效果，因此我們也可以使用該二值的差異來表達氣體的可壓縮能力。該二值的比值(是的是比值，雖然前面的描述可能會讓人以為是差值)有個熱力學上的專有名詞，叫「絕熱指數」(Heat Capacity Ratio)，簡寫為 κ。

\[ κ = \frac{Cp}{Cv} \]

由於 $C_p$ 總是大於 $C_v$，因此絕熱指數總是大於 1。這個絕熱指數與氣體的膨脹能力直接關聯，並且在後面的各種分析計算中我們也會不斷看到它的身影。回顧前面給出的空氣比熱容數值，我們可以知道空氣的絕熱指數大約就是 1.4。

膨脹、壓縮、做功

Figure 3. 汽缸、活塞、與計算相關的定義標示

了解前面的氣體特性之後，我們將眼光放回汽缸與活塞上面。如上圖所示，假設一個形狀中規中矩的圓柱汽缸內有一隻活塞。如果我們用手將活塞從位置 1 推到位置 2 的話，我們的手需要出多少能量、做多少功呢？

假設汽缸內部截面面積為 A，活塞在位置 1 的時候與汽缸頭的距離為 $X_1$，此時汽缸內的空氣體積為 $V_1$；活塞到了位置 2 的時候與汽缸頭的距離為 $X_2$，彼時汽缸內空氣體積為 $V_2$。我們先暫時簡單化一下，暫時假設汽缸內的空氣壓力不會變化，也就是 $ P_1 = P_2 = P $，晚一點再把壓力變化的因素加回來。那麼從 1 到 2 的過程所需要的能量(E)，按照機械功的定義，即為力(F)乘上移動距離：

\[ E = F ( X_1 - X_2 ) \] \[ E = P A ( X_1 - X_2 ) \] \[ E = P ( V_1 - V_2 ) \]

也就是說，活塞做功其實就是壓力和容積乘積的差。接下來我們將上面的式子以積分的型式改寫：

\[ E = \int_{V_1}^{V_2} \mathrm{P}\,\mathrm{d}V \]

剛才我們做了一個不切實際的假設，那就是無論活塞怎麼壓縮空氣，空氣的壓力都維持不變。這當然是不可能的事情，只是為了先簡化理解而不得不做的假設，那麼現在我們將這一部份的因素加回來。雖然現在還不知道氣體壓力和體積之間的準確關係，但至少我們知道壓力和體積有關係，且隨體積改變，那麼我們就假設壓力為體積的函式並改寫積分式：

\[ E = \int_{V_1}^{V_2} \mathrm{ \mathit{P}(V) }\,\mathrm{d}V \]

當然啦，如果 P 並不隨 V 變化，而是從頭到尾維持一個數值不變，那麼從下面即將要說明的積分原理圖來看就會知道，這個積分式可以直接退化變成 $ E = P ( V_2 - V_1 ) $，與前面我們沒用積分的結果相合。 (正負號的差異後面再說明)

Figure 4. 積分原理：將一條隨意曲線分割成三個區塊，然後把三個長方形的面積加起來就當作是曲線面積了！

對於沒有學習過微積分的讀者請不要感到害怕！這裡不會要你去推導解算微積分，這個事情我來做就好了，我們的重點在於理解。

積分的意義其實就是在算一條曲線下的面積，例如上圖(Figure 4)所示的汽缸內體積壓力關係圖，我們要算的其實就是體積 $V_1$ 到 $V_2$ 之間，壓力變化線下面的面積。對於這種需求而言，我們有一種很笨很原始的方法，就是把體積的部份切割為幾個區段，以上圖示例來說我切了 3 塊區間，每一個區塊的寬度就是 dV。管他壓力變化呢，在每個區間內我就假定壓力是固定不變的，這樣面積就好算了吧？單一區塊內的面積就是 $ P \cdot dV $，然後把 3 個區塊的面積都加起來，這就是我們要的 P-V 總面積了。

當然我們看圖就會發現，這樣分 3 塊計算下來的樣子雖然有了，但誤差挺大！如果要降低誤差使結果更加精準，我們可以切割為更多區塊來計算，30 塊、300 塊、3000 塊……。如果我們將它切割為無限多塊，那麼算出來的結果就是零誤差的實際結果了；而這，其實就是積分的原理，而上面的積分式也就是在表達一樣的意思！

那麼要繼續探究這個問題，我們就要知道當空氣體積變化的時候，壓力與之的對應關係了。前面介紹過的理想氣體萬用方程式仍然可用，但顯然不太夠用，因為我們知道空氣在壓縮的時候，溫度和壓力同時都會上升(相反在膨脹的時候二者同樣都會下降)，然而卻無法知道它們各自上升了多少？因此這裡還要再介紹幾個有關的氣體狀態關係式，這些式子不像萬用方程那樣萬用，而只有在絕熱可逆的情況下可以使用，好在我們所在意的汽缸活塞壓縮和膨脹正好就符合這樣的條件，因此：

\[ P_1 V_1^κ = P_2 V_2^κ \] \[ T_1 V_1^{κ-1} = T_2 V_2^{κ-1} \] \[ T_1^κ P_1^{1-κ} = T_2^κ P_2^{1-κ} \]

上面三條算式中出現了很多眼熟的 κ，這就是氣體的絕熱指數，我們前面有解釋過，因為我們討論的例子裡面裝的就是空氣，因此可以直接帶入 κ = 1.4。這樣我們只需要知道活塞在某一個位置時的氣體狀態(P、V、T)，就可以算出活塞在另一個位置時的氣體狀態。如果汽缸內初始裝的是一般室溫條件(101325 Pa、300 K)的 3 升空氣，假設我們最終的狀態 2 會把空氣體積壓縮為原本的十分之一(也就是 0.3 L)，那麼透過上面三個方程(其實只要第一個就可以了)加上前面的理想氣體方程，我們就可以算出位置 2 下壓力與溫度的各自數值了。事實上不只可以算出位置 2 的氣體狀態，連活塞在中間每一個任意位置的氣體狀態都能夠計算出來，結果就會如下圖(Figure 5 與 Figure 6)所示。

Figure 5. 汽缸內壓力與體積關係圖

Figure 6. 汽缸內溫度與體積關係圖

從圖表的呈現可以明顯看出，汽缸內空氣的壓力和溫度都隨著我們不斷壓縮缸內的空氣而增加，此外壓力的增加比起溫度的增加是更為劇烈的。相比於溫度隨著壓縮的升溫，壓力的增加趨勢明顯是更為急遽的指數級變化，這個現象很重要，會貫穿整個功效分析過程。

關於這個現象我們可以這樣理解：我們不壓縮，只靠加熱就能讓缸內氣壓增加，這點符合生活常識，很容易理解；我們壓縮氣體也會直接導致氣壓增加，也很符合生活常識；而壓縮過程同樣會導致氣體溫度上升，壓縮本來就會增加壓力了，這邊它又還升溫，於是壓力就爬的更快了！

那麼活塞在任何一個位置(V)時的壓力(P)就可以表示為：

\[ P = P_{ref} \left( \frac{V_{ref}}{V} \right)^κ \]

上面的 $P_{ref}$ 和 $V_{ref}$ 可以選用任何一個已知條件下的氣體狀態，可以選用 $P_1$ 和 $V_1$，也可以選用 $P_2$ 和 $V_2$，看在做計算的時候哪一邊的數值更容易事先取得而定，因此這裡才以 $P_{ref}$ 和 $V_{ref}$ 表示之。

知道了壓力隨體積的變化關係之後，前面的活塞做功算式就可以寫成這樣：

\[ E = \int_{V_1}^{V_2} \mathrm{ P_{ref}\left( \frac{V_{ref}}{V} \right)^κ }\,\mathrm{d}V \]

積分後的結果就是：

\[ E = \frac{ P_{ref} V_{ref}^κ }{ 1 - κ } \left( V_2^{1-κ} - V_1^{1-κ} \right) \]

然後你會發現，$V_1$ 和 $V_2$ 可以互相調換位置，算出來的數字是一樣的，只不過差了個正負號。它的意義在於做功的方向，如果活塞從位置 2 移動到位置 1，那是活塞在對外面做功，所以最後的功是正值；如果活塞從位置 1 移動到位置 2，那是外面在對活塞做功，活塞內的氣體吸收了外面的能量，因此這個功是負值。這告訴我們一個重要的性質，在兩端條件相同的情況下，氣體壓縮所需要的能量和膨脹所放出的能量是一樣的。意思就是說，無論活塞膨脹的時候產生的動力讓我們有多開心，但是我們也需要付出同樣的能量才能把活塞推回那個位置！

Figure 7. 活塞除了受汽缸內壓力推動之外，還受環境大氣壓力推動

最後別忘了考慮環境壓力在活塞運動中產生的作用。如上圖(Figure 7)所示，汽缸內的活塞其實一直受到兩股氣壓的作用，一個是缸內的氣壓，另一個是外面的大氣壓力($P_{atm}$)。在壓縮的過程，我們的手除了要對抗缸內不斷增強的氣壓之外，外面大氣壓力其實也幫我們推了一把；在膨脹過程，活塞除了受到內部高壓空氣推動之外，也同時需要對抗大氣壓力的阻力。因此我們的活塞做功計算式其實需要修正一下，要扣除大氣壓力的影響；不過還好大氣壓力自始至終維持同一個數值不變，所以大氣壓力對活塞所做的功計算就非常簡單。修正後的活塞做功計算式如下：

\[ E = \frac{ P_{ref} V_{ref}^κ }{ 1 - κ } \left( V_2^{1-κ} - V_1^{1-κ} \right) - P_{atm} ( V_2 - V_1 )\]

膨脹做功

現在來快速複習一下四行程發動機的運作：壓縮空氣，加熱空氣，然後膨脹空氣。這時會不會好奇一個問題：為什麼要壓縮空氣呢？如同我們前面計算出來的結論，壓縮是需要耗能的，而且需要的消耗的能量和膨脹時放出的能量一樣多！那麼這樣繞了一圈路，非得要先壓縮再燃燒膨脹的意義何在呢？存在即真理，壓縮步驟當然是有大用，因此我們真正的目的其實不是去解釋壓縮有沒有作用，而是去理解這個壓縮的步驟到底在引擎的原理中扮演什麼角色、起到何種作用？

剛才我們已經研究過如果用手去推動活塞壓縮空氣所需要的能量，那麼現在反過來看看，當氣體從高壓之下膨脹時能做多少功？

因為壓縮和膨脹的過程是完全一模一樣的，因此上面的圖表和算式都可以拿來直接套用。我們知道氣體的壓力隨著汽缸容積的變化，分佈的極不平均，壓力幾乎全都聚集在圖表最左邊的區域。因此我們知道活塞在膨脹運動的初始階段其實是最能夠做功的時候，然後隨著氣體繼續膨脹，活塞也繼續推動繼續出力，但是能釋放出來的能量就愈來愈有限了。為此我也做了一張圖表如 Figure 8，圖表的意義為這個汽缸如果在此例的膨脹過程中，到了某一個容積後就讓它停下來的話，那麼活塞至此為止能夠釋放多少機械功出來？例如當汽缸內空氣從 0.3 L 膨脹到 1.0 L 為止的話，活塞大約做了 600 J 的功；如果繼續膨脹到 1.5 L 的話，那麼活塞大約累計做功 800 J。而大約在 2.0 L 的位置，活塞的機械能量都差不多已經釋放完了，往後繼續膨脹下去雖然還能夠再繼續做功，但是增幅範圍已經非常小了。

這個結果很重要，我們從前就提過一般活塞引擎因為曲軸機械結構的原因，基本沒辦法讓氣體膨脹到完全沒力為止，而是活塞到底了就停了，接下來活塞得往回走，然後這些還有膨脹力的燃氣只好被捨棄並排放掉；然而這張圖表卻告訴我們雖然以上的理論是正確的，但是被浪費掉的能量其實可能並不會太可觀，還在一個可以接受的小幅損失範圍內。

Figure 8. 活塞在氣體膨脹過程的累積做功分佈

壓縮的意義(動力循環分析)

剛才前面都還在玩手推壓縮再膨脹回來的遊戲，單純就是在了解壓縮和膨脹而已，但是我們手上的這顆引擎還並沒有能夠對外輸出功率的能力，那麼現在我們要開始來給空氣加熱了。

我們就拿前面所用的同樣的汽缸活塞配置來做分析，同樣使用地面大氣條件的空氣取 3 L 作為缸內初始容積；並且為了方便做對比，後續所有分析的配置都採用同樣的初始條件。作為第一個分析對象，我們就仿效在 Otto 之前的人們一樣，不用壓縮空氣就直接加熱，然後讓空氣膨脹。我們就來給空氣加熱增加個 1000 度的溫度，經由前面介紹過的比熱容算式，我們可以知道這需要投入 2772.7618 J 的熱量；而後面的所有其它配置的分析，我們也完全比照這個實驗，給空氣投入 2772.7618 J 熱量，這樣可以更容易的進行互相比較。結果如下圖(Figure 9)：

Figure 9. 無壓縮程序(即壓縮比為 1)時，加熱空氣與膨脹做功，氣體的壓力變化過程(動力循環圖)

除了多了加熱之外，所有的一切就和前面介紹過的內容一樣。給空氣增溫後，溫度來到 1300 K，壓力來到 439075 Pa。在膨脹的行程裡，我們就讓活塞可以無限跑，暫時先別管這樣的引擎機械結構要怎麼打造？總之我們有足夠的空間讓活塞充份膨脹就是了！最後當缸內氣體膨脹為 8.7 L 的時候達到內外壓力平衡，活塞也停止在此。總結缸內容積膨脹了 2.9 倍，做功 564.6911 J，效率為 20.37%。這個結果好不好？我們暫且不評論，就當作個比較基準，看看後面其它的情況結果如何再來做個比對。

此外還有一個現象值得我們注意。缸內壓力隨著氣體容積的增加而持續減小，當內部壓力與外部環境壓力相同的時候，活塞完全做完所有的功，再也榨不出更多動力；而此最終狀態下的氣體溫度約為 855 K (我們的初始氣體溫度為 300 K)，呼應了我在前篇 ^[2] 所講述的內容：「氣體吸收能量而增加了壓力和溫度，其壓力被我們拿來做功，可是其溫度我們卻無法利用，只能讓它成為系統廢熱然後排放出去；然而即便溫度的增加需要吸收能量並且沒有用處，我們卻不能不給它加熱來提取其壓力。」

Figure 10. 無壓縮程序、與加入壓縮程序的動力循環比較圖

那麼現在我們來試試看先將空氣壓縮後再燃燒的情況。先將空氣在汽缸內壓縮 3 倍體積，也就是將容積從 3 L 壓縮為 1 L (過程即為 Figure 10 中的藍色線段)後，再將它升溫 1000 度，然後再讓它膨脹，也同樣的膨脹不受限。結果是壓縮氣體花費了 216.7181 J 功，膨脹最終來到 6.8 L，膨脹倍率 6.8 倍，膨脹做功 1400.2796 J。雖然壓縮氣體這程序消耗了可觀的能量，但是這麼一來一回，扣掉壓縮氣體所花費的能量之後，機械功靜輸出還有 1183.5615 J，比前一個未壓縮的案例還多，熱效率則為 42.69%。

我們發現不管是機械功的輸出、或是熱效率，多了一個壓縮過程的情況都比前一個沒有壓縮的情況表現更佳，僅僅加了三倍的壓縮就使效率上升約一倍！這是為什麼呢？觀察圖表就能發現，雖然我們投入的熱量是一樣多的，提升的溫度差也是一樣的，但是加了壓縮過程的版本在加熱的時候，壓力的增幅明顯高過沒有壓縮過程的增幅。於是我們接下來再試試看如果加熱前再壓縮更多一點會怎麼樣呢？

Figure 11. 再加倍壓縮的動力循環比較圖

這次我們在加熱空氣之前先將空氣壓縮 6 倍，也就是把 3 L 空氣壓縮至 0.5 L 容積大小。結果壓縮氣體花費了 542.8529 J，最終膨脹容積來到 6 L，膨脹倍率 12 倍，膨脹做功 2018.4921 J，靜輸出功 1475.6392 J，熱效率來到 53.22%。整體表現又比壓縮 3 倍的版本更好了，並且觀察圖表似乎也印證了一件事： 在加熱空氣前，如果空氣的壓力愈高，那麼加熱後的壓力增幅也愈大！ 事實上繼續嘗試壓縮 12 倍、壓縮 24 倍的圖表也同樣表現出了這樣的趨勢(Figure 12)，當壓縮倍率來到 24 倍的時候，靜輸出功 1892.2437 J，效率來到 68.24%。這就是燃燒前先壓縮的精妙之所在，也是為什麼但凡任何燒油的發動機想要在燃油效率上有所突破的話，總是想盡辦法想要增加壓縮率的原因！

這就是燃燒前「壓縮」這個動作給發動機性能表現所帶來的決定性影響力，也是 Otto 引擎能夠名流青史的根本原因。事實上在 Otto 引擎發明之前就已經存在許多空氣引擎了，它們就像最前面的那個沒有壓縮的引擎一樣，直接燃燒加熱空氣，然後膨脹推動活塞。當然這種引擎整體功效都奇差無比，也就不難想像為什麼後來 Otto 先生一推出自己的發明就能夠收穫一堆訂單了！進氣、壓縮、燃燒、膨脹、排氣，這幾個活塞引擎動作的基本步驟，也許在我們現代的後輩人眼裡並不是那麼讓人耳目一新的嶄新思想，甚至並不覺有多麼了不起。但是這就像是世界上第一個繞出迴紋針的人一樣，試想如果把你生在他們的那個年代，又有多少人能夠想得出來，在燃燒前要先給空氣加壓會這麼有用呢？

Figure 12. 繼續嘗試更多壓縮程度的動力循環比較圖

從解析理論來解釋壓縮的作用

好的，至此我們確實能從圖表上明顯的看出壓縮這個動作，它在整個發動機運作原理中所具有的角色地位。但是有沒有能夠從數學原理上給我們展示，為什麼壓縮的愈起勁，加熱後的壓力增加幅度愈大的原理呢？我們這裡用理想氣體方程來一讀加熱前後的氣體狀態關係：

\[ \frac{ P_3 V_3 }{T_3} = \frac{ P_2 V_2 }{T_2} \]

Tip	雖然在任意兩個狀態之間可以用狀態 1 和狀態 2 表示，但是一般在 Otto 循環的理論分析上有著比較廣泛的習慣寫法，所以這裡、以及下面的解說中都將採用計算分析中慣例的表示：壓縮前的氣體狀態為狀態 1，壓縮後為狀態 2，燃燒增溫後為狀態 3，膨脹後為狀態 4。

由於理想的燃燒是瞬間完成的，燃燒前後汽缸容積並沒有變化，$ V_3 = V_2 $，因此：

\[ P_3 = P_2 \frac{T_3}{T_2} \]

投入熱量加熱空氣會使空氣升溫，並且定量的熱量對定量的氣體會升高同樣的溫度差，這個差值與氣體當下的溫度、體積、壓力等無關，因此我們假定加熱動作使氣體溫度增加了 $\Delta T$：

\[ P_3 = P_2 \frac{ T_2 + \Delta T }{T_2} \] \[ P_3 = P_2 \left( 1 + \frac{\Delta T}{T_2} \right) \]

這裡我們可以發現，加熱後的壓力 $P_3$ 其實就是將加熱前的壓力 $P_2$ 放大一個倍率。當然我們可以增加 $\Delta T$ 的量來讓 $P_3$ 更大，但是要增加 $\Delta T$ 量就要投入更多的熱量，對於想要改善效率的情況來說意義不大。因此我們這裡假定 $\Delta T$ 固定為一個值不變，意義是我們想要找到一個規律，在投入的熱量不變的情況下能讓 $P_3$ 盡可能變得更大。那麼這個看上去並不複雜的方程式就告訴我們，想要讓 $P_3$ 變大的話，增加 $P_2$ 或降低 $T_2$ 都有作用。

對於降低 $T_2$，也就是降低壓縮後的溫度這點實現比較困難，而且實際效果幫助比較有限。具體影響效果還得考慮 $\Delta T$ 的大小，假設 $\Delta T$ 和 $T_2$ 的值差不多大的話，那麼 $T_2$ 縮減一半，也才能讓 $P_3$ 增為 1.5 倍，何況實際上該二者的值距離「差不多」可能還有點遙遠。具體要操作的話，就是要在氣體壓縮的過程中儘量去對氣體散熱，而這其實也是那些有增壓器的汽車上面所配備的中冷散熱器所帶來的副作用；不過你可千萬別把空氣都壓縮完了才去散熱啊！這時空氣壓縮該付出的功都已經付進去了，反而你降低了多少溫度最後還要燒更多的油才能把溫度加回來，完全多此一舉！

如果想要採行降低 $T_2$ 的方案的話只有兩種方法：或者是在壓縮的過程中一邊同時在散熱，或者是想辦法讓吸進來的環境空氣溫度降低($T_1$)。其實降低進氣溫度也是實務上可行的做法，但是我們要怎麼控制外界環境的溫度呢？我們無法改變外界空氣的條件，但是我們自己的工作時段是可以調整的。所以在冷天環境空氣溫度低的時候，內燃機車輛的發動機效率會略為增加 (不過太冷以致於機油溫度都很難上升至工作溫度的情況不在此考量)，同樣的原因也是為什麼貨運飛機喜歡在半夜起降的原因其一；不過這些方法對於燃油效率的改善幅度，也真的就只是那麼一丟丟！

至於為什麼成效非常有限？我們的進氣溫度 $T_1$ 是 300 K，也就是大約 27℃；那麼你能夠降低多少呢？光是要讓進氣溫度減半，那就是 150 K，那可就是 -123℃ 啊！能辦到嗎？對於一般不同天氣和季節的氣溫差值只有十幾二十度，了不起幾十度的氣溫變化量來說，幫助還真的就只是那麼一丟丟。因此降低溫度的做法效果並不好，只能作為次要的輔助手段。

既然降溫這條路的實際作用比較有限，那麼增壓這個方法呢？上列方程式告訴我們，增加 $P_2$ 的大小可以等比例的放大 $P_3$ 的大小，效益顯著；至少比起降低 $T_2$ 所產生的幫助效果、以及實務上的難度而言，增加 $P_2$ 的方法可簡單好用多了，而實務上也是如此。這就是為什麼所有的燃燒式發動機都在一股腦努力用力壓縮空氣的原因！聰明的讀者可能會發現一個小問題：「不對啊！壓縮同樣也會升溫，會增加 $T_2$ 的大小，這樣不會不好嗎？」的確，壓縮會導致溫度上升，可是有兩項因素導致這麼一來一回之後，增壓帶來的效益還是好過增溫帶來的損害：其一是如前述 $T_2$ 的增加對於 $P_3$ 的影響並不是那麼嚴重；其二是如同我們前面提過的，壓縮的時候不管壓力或溫度都會同步上升， 但是壓力的增長速度比溫度的增加速度更快的多！ 如此一來二往下來，就成了在燃燒前給空氣增壓，可以使燃燒後的壓力增幅倍增現象的結果。

計算總功率

我們至此已經完成基本的發動機循環分析了，但是有些朋友也許會有個疑問：這個能量輸出的單位怎麼和平常我們聽說的馬力什麼的不一樣啊？什麼是焦耳，為什麼用焦耳？為什麼這個動力的數字與平常熟悉的數字完全不一樣啊？

其實以上的分析計算得出來的結果，都是在單次動力循環裡面所吸收、和釋放的能量。如同我在前篇^[2] 所述，一般實務上我們可能會更加關注的是發動機做功的速率，也就是功率，而非單次的做功能量。但是從單次的活塞做功輸出計算出功率其實很容易計算，既然功率就是做功的速率，因此我們只要知道發動機在一段時間之內到底重複了多少次單一循環就好了。

就拿上面壓縮比為 24 的那個分析結果作為例子吧，該例分析的結果為單次循環可以得到 1892.2437 J 的淨功輸出。假設該發動機曲軸轉速為 3000 RPM，也就是在一分鐘時間內轉了 3000 圈，也就是一秒鐘 50 圈，又由於四行程發動機是曲軸轉兩圈才完成一次動力循環，因此它一秒鐘實際做了 25 次動力功輸出。因此最終它的功率就是 1892.2437 J 乘 25 得 47306.0925 W，單位從焦耳變成瓦特。而如果這顆引擎不只有一個汽缸，假設它有 4 個汽缸好了，那麼結果就是單缸功率乘以 4，得 189224.37 W；或者把單位換算成千瓦小時就變成 681207.732 kWh。

不過在發動機實用領域可能更多人熟悉的功率單位是馬力，如上面的瓦數換算成馬力就是 257.27 (hp)。馬力其實是因為歷史的原因，古時候因為是以馬作為測量基準，所以叫馬力；但是因為馬力其實也同樣是功率單位，所以可以與標準功率單位互相轉換。最終我將整個發動機的功率計算方式簡單整理如下，讓讀者們可依自己的需要和習慣自行計算換算這些數字：

\[ 發動機功率(W) = 單缸單次循環淨功(J) \cdot 汽缸數量 \cdot \frac{轉速(RPM)}{ 60 \cdot 2 } \]

\[ 功率(hp) = \frac{功率(W)}{735.49875} \]

至於效率呢？效率只與單缸單次循環的結果有關，至於轉速快慢、缸數多少等等，並不影響效率的數字；當然這是指完美條件下的純理論分析，至於打造成一個真實發動機後的運作相關損耗另當別論；功率的輸出其實在考量運作損耗之後也不是單純的與轉速和汽缸數成比例關係，不過同理暫且忽略不管。

總結

在本篇，介紹了氣體對於體積、壓力、與溫度彼此之間的關聯性和消長關係，然後通過對氣體加熱升溫，產生活塞做功輸出的過程與特性。也介紹了如何在單缸的機械做功輸出、與發動機整體功率或馬力數字之間互相轉換的簡單計算方法。

更加關鍵的是，本篇解答了發動機之所以在燃燒前要壓縮空氣的原因，從氣體的物理原理上解釋了壓縮的作用，並用數學與計算看見了壓縮帶來的效果。因為先壓縮空氣能夠使得後續的燃燒增溫取得更大的壓力增幅，進而能夠輸出更多動力，並提升燃油能量轉換效率；並且從理論計算中得到一個結論：在沒有其它意外因素的干擾之下，壓縮比是愈高愈好！

至此，我們從純物理的角度，理解了活塞發動機最根源最單純的動力原理。不過，理論與實際總有些不完美的落差，比如說壓縮比既然越大越好，那為什麼當前的汽油發動機壓縮比卻只停在 10 左右就止步不前了呢？要解答這些問題，就得從理論走進現實，了解真實的發動機所面臨的各種不得以；這些，我將放在下一個篇章繼續講解……

1. Table of specific heat capacities

2. 活塞引擎 7：功率與效率

活塞引擎 7：功率與效率

Sat, 26 Oct 2024 16:47:15 +0800

本篇我想要介紹發動機的兩項重要的性能指標：功率與效率。這是給那些對功率與效率是什麼沒有概念的讀者準備的主題，而不會進行實際的分析，因此如果您已經知曉功率是什麼、熱效率是什麼，那麼就可以跳過本篇，繼續閱讀下一篇了。

曾有一個小朋友問過我一個問題，說那些戰鬥機很耗油啊，每次看到說油這麼幾十萬幾百萬的燒就很心疼 (確實小朋友很可愛，即便燒的不是自己的油也會心疼)，那有沒有可能改進設計，這樣只需要加少少的油就可以了？ (我想這個意思可能是加油的量減少為十分之一以下，但還是維持原有的一切包括飛機性能、任務頻率等等) 我回答他說沒有辦法，因為飛機的動力就是從油(其實叫燃料更合適)來的。除了縮減訓練飛行的頻率這個方案之外，節省了燃料消耗(顯然不是微幅的，而是大量的)的飛機，它的性能肯定不好；如果要維持飛機的性能，那麼就少不了動力的供應，而想要引擎提供怎樣的動力供應，就得要對等燒掉怎樣多的燃料。

見小朋友仍然不解，我就開始和他一起整理一番……
飛機的推力從哪裡來的？螺旋槳。 (我們討論的是活塞引擎螺旋槳飛機，正好符合目前主題)
那麼螺旋槳轉動的力量從哪裡來呢？意思是是誰提供的呢？是螺旋槳軸，也就是引擎動力軸。
那麼引擎軸的力量哪來的呢？是飛輪。(其實要說是曲軸也可以)
那麼飛輪的力量哪來的呢？是曲軸。
那麼曲軸的力量哪來的呢？是曲柄。
那麼曲柄的力量哪來的呢？是活塞連桿。
那麼活塞連桿的力量哪來的呢？是活塞。
那麼活塞的力量哪來的呢？是膨脹的氣體。
那麼氣體為什麼會膨脹呢？因為我們燃燒了燃料，將空氣加熱了，空氣受熱於是膨脹了。

於是一起推理了一遍，原來是汽油燃燒了之後加熱空氣使空氣膨脹，膨脹的氣體去推動活塞，活塞去推動活塞連桿，然後曲柄、曲軸、飛輪、引擎軸，然後是螺旋槳，然後螺旋槳再去推動空氣把空起往後推，於是反作用力提供了飛機前行的動力，驅動飛機前進。總結起來就是：我們燃燒燃料得到飛機的推進力，最終是依靠著燃料的燃燒產生推力供給飛機使用；至於中間那坨機器(也就是發動機)的作用，其實就是使用各種巧思來將燃料燃燒的熱能轉換成為力量的機器。中間的這個機器可以是以活塞汽缸機械原理運作的、也可以是渦輪原理打造的、或者是某種燃料電池轉換原理設計的、或者是任何你巧思發明出來的某種奇妙運作原理發明的新機器，但無論如何，它們其實都在做同樣的一件事情：「將燃料本身蘊藏的化學熱能轉換成我們要的機械動能。」至於不同的引擎結構原理，其實也就是能量轉換的方法手段不同罷了；但是不論使用什麼手段、方法、原理、設計，改變的只是能量轉換的方法途徑，並不能夠改變能量轉換的本質， 更不可能因為使用某種新發明的轉換設計而憑空產生更多的能量， 因為終歸最後，所有的能量都還是從燃料來的！

Figure 1. 引擎就是一個能量轉換器，用來將然燃料的化學熱能轉換成機械動能

如上圖所示，我們現在將發動機的內部構造給隱藏起來，無論它實際上是幾個汽缸的、怎麼排列的、或是渦輪式的、瓦特式的、還是什麼燃料電池式的，總之就是一個大黑盒子。我們不知道(或者暫時不想知道)黑盒子裡面的東西，反正就是一個神祕的機器，只知道我們把燃料從左邊丟進去，機器一通運作之後就會把燃料變成機械動力，從右邊的轉軸輸出出來，順便會產生一些諸如廢棄廢熱等副產品；至於動力產生出來後要接去哪裡就隨使用者的意思了。那麼對於這樣一臺用來轉換能量的黑盒子機器，作為使用者而言自然就會關注起它的兩項重要的性能指標：功率、與效率。

功率

什麼叫功率呢？就如同它的字面意義，是做功的率。這個功也就是能量的其中一種表現方式，如果沒聽過功或能量的話，可以暫時理解為產生的動力；那麼功率也就是機器產出動力的速度了。那為什麼我們不直接講力不是更加直白嗎，為什麼要講什麼能量呢？的確看力的大小是比較容易理解的，套用在轉軸上也就是力矩，只要小學高年級程度就能夠理解，但是如果只看容易理解的力或力矩大小，其實反而會產生更多更加複雜化的問題。比方說用在 F1 賽車上的引擎軸所產生的力矩普遍偏小，基本遠小於一輛 3.5 頓卡車引擎軸的力矩，然而我想應該沒有人會認為 F1 賽車的引擎動力比小卡車還要低！這是因為一顆引擎它可能產生的力矩不大，但是人家活塞動的快；也有的引擎活塞動的不快，但人家汽缸大啊。於是會發現，車子跑的快不快、引擎有動力沒動力，其實不能只靠其所容易被理解的力與力矩來判斷，除了轉軸力矩之外還往往需要一並考量引擎轉速。甚至於在變速箱的作用之下，低扭力(就是引擎軸力矩)但高轉速的引擎一樣可以拖動大負載。

既然不能夠只看發動機產生的轉動力矩也就是扭矩來判斷動力輸出的大小程度，也不能夠只看轉速來判斷，那麼我們就需要一種指標數值來良好適當的指示某一臺機器所輸出的動力大小；又既然發動機就是一個將化學能量轉換為機械能量的轉換裝置， 那麼我們就直接以產出的能量大小來評斷所謂的動力輸出大小吧。 這就是為什麼發動機總是喜歡用功率來表示能量輸出的原因了，因為這個「功」其實就是能量的眾多表達形式中的一種，也就是機械能的表現形式。

那麼功就功吧，我已經知道它是一種能量的單位了，那為什麼又要來個「率」呢？如果單單只看能量值也就是功的輸出其實意義有限，就好像在瓦斯爐上面燒一壺水一樣，就算用的是小瓦斯爐，只要給它足夠的燒煮時間，一樣可以燒開一大鍋水。因此我們通常關心的其實不是瓦斯爐能夠產生出多少熱能，而是關心它在一個時間範圍內所能產生的熱，也就是熱的產生率。因此發動機也是一樣的，其實我們關心的不是發動機所能夠產出的能量，因為只要給它足夠的運作時間，小小發動機一樣能夠產出大大的功。所以我們更加關心，也是用來評比一臺發動機的動力大小的指標，就成了發動機它做功的速率，也就是功率。

效率

從上面的示意圖中，注意到標示的「廢熱」這個部份，它是發動機運作時產生的無用副產品，卻昭示著發動機的另一項重要性能指標 — 效率。

截至目前為止，人類造不出完美的機器，因此各種損耗也充斥在人造的機器中。我們的機器作為一種能量轉換器它並不能夠完美的轉換能量，而是會有一定程度的折損。比方說我們丟入一公升的燃料，燃料燃燒能產生出 1000 焦耳的熱能，理論上完美的神造機器就能轉換出 1000 焦耳的機械功從引擎軸傳出去，但是我們人造的機器卻可能只能轉換出 300 焦耳的功，因此轉換率就是 300 / 1000 = 30%。這就是所謂的能量轉換效率，也就是引擎效率，或者因為我們的引擎絕大部份都是以機械和熱膨脹等原理運作的，所以經常也能看到其它文章裡會以「熱效率」稱呼之，只不過不管用詞如何，其所表達的就是輸入能量與有效輸出能量的轉換比例。其計算原理也很簡單， 效率的根本定義就是： 你投入了多少熱能(也就是燃料)，然後產生了多少機械功輸出，兩者的比例關係即為轉換效率。將投入熱量作為分母、產生的動力作為分子，兩者一除，就得到了一個介於 0 到 1 之間的轉換效率數字，此值也能以百分比表示。效率數值愈高表示引擎效率愈好，也就愈省油。 (實際上目前所有現存燒油的發動機，這個效率都不到 50%，通常約在 20% 至 40% 左右)

我們現在知道了引擎的能量轉換效率不是 100%，而是會產生一些折損，而且以目前的科學技術水準來說通常這個折損還是過半的！但是能量應該是守恆的，就如同質量守恆一樣，能量既不會憑空產生，也不會憑空消失，那麼這就奇怪了，我們所謂損失的那些能量去了哪裡了呢？確實能量不能無故消失，而且也並沒有消失，只不過是有部份的能量被轉換成了我們無法利用的能量罷了！意思就是說燃料燃燒出來的熱能，只有其中一部份被引擎轉換成為能夠被利用的機械功，而另外的其它部份則轉換成了我們無法利用的能量。因為無法捕捉並利用這些能量，因此這些能量就逸散出去外面，成為上圖所示的副產品：廢熱。

關於無法利用的廢熱，我們先從比較容易理解的部份來說明。在活塞運動中我們將氣體膨脹的壓力傳遞給活塞，讓活塞去推動後面一系列連桿、曲軸等機械，這些機械結構彼此互相的摩擦運動都在消耗著活塞所傳遞出來的能量，所以可以說這些機械結構的運動過程消耗掉了一小部份理想上可以往後傳遞輸出的機械能。而小學生都知道，摩擦會產生熱，也就是說這些機械結構在將能量從活塞傳遞到輸出軸的過程中，對這些能量抽了一點稅，並將它轉換成摩擦熱能，使引擎發熱了。

不過實務上，齒輪與機械結構的能量傳遞效率非常高，掐指一算大約都有 98% 以上，所以其實這些機械結構摩擦所偷走消耗的能量只算是皮毛而已，而真正摩擦消耗掉更多能量的其實是活塞與汽缸。為了保持密封的緣故，活塞與汽缸壁之間其實卡的有點緊(主要是活塞環)，因此會產生很大的摩擦阻力，至少相比於連桿、曲軸、齒輪這些零件的阻力來說是大得多的多了。雖然為了減少活塞運動的阻力，人們已經發明了接觸面積相對比較小的活塞環，還對活塞汽缸之間噴上機油等做潤滑處理，已經最大程度的減小了活塞的摩擦消耗，但是活塞摩擦所產生的耗損依然無法被忽視；而這也是為什麼現代強調省油的汽車，都會儘量減少汽缸數量的主要原因之一。

雖然活塞與汽缸壁之間的摩擦已經夠大了，但其實把活塞、和其它所有機械零件的消耗加總起來，吃掉的引擎動力在整個引擎產生的廢熱裡其實也不過是零頭而已，而廢熱產生的真正主要大頭其實來自於發生在汽缸裡面的壓縮、膨脹、與燃燒反應。這一個部份比較難理解，至少不像機械摩擦消耗動力並產生熱這樣這麼能夠直覺的想像，其中比較詳細的原理我會在下一篇章進行探討，這裡只說個比較能夠容易理解的大概。汽油與空氣混合的氣體被點燃後成為高溫高壓的氣體，請注意這裡的「高溫」與高壓，因為只有壓力被我們用來推動活塞，至於氣體的高溫對於推動其實一點用處都沒有，然而它的升溫確著實吸收了燃料的能量；矛盾的是，如果不對氣體加熱，又如何使氣體產生壓力呢？於是為了得到高壓氣，我們必須得加熱，這些吸收了大量燃油能量而升高的溫度卻無法被加以利用，只能無奈的將這些吃飽了而溫度上升了的氣體給排放出去。而這，其實才是引擎廢熱的最主要產生來源，也是吃掉引擎效率的主要罪魁禍首！

Figure 2. 汽缸內的空氣被加熱後，產生壓力推動活塞 ^[1]

效率的重要性

我們這裡看發動機就是一個能量轉換器，將燃料的化學能轉換成機械動力，順便產生一些廢熱。如同上面所說，效率指的就是上面這個能量的轉換率， 轉換率愈高的引擎其效率就愈高，運轉起來就愈不會發熱。 假如有一個真正理想的效率 100% 發動機，那麼它在產生動力的同時，引擎本身一定是不會升溫的；相反的，如果一個引擎產生動力的同時自身還變得燒燙，可能還大量排放高溫廢氣的話，那我們就能知道它的效率一定不高。 (所以電動馬達的效率是非常高的，轉起來也幾乎不會燙，完全符合假設條件；即便有些人可能會說馬達轉起來也是會發熱的，甚至有些馬達還會需要散熱片，但是馬達的發熱量對比汽、柴油引擎的發熱量而言，那幾乎就可以算是不會發熱了！)

我想對於許多孩童到學生階段的熱血男孩而言，可能更加關心的是引擎的總功率吧！畢竟只有足夠大功率的發動機，才能夠帶動汽車在賽道上疾馳，帶動戰鬥機在空中高速飛行、進行炫麗的大角度機動動作，或者推動萬噸級別的重型武裝船艦在一望無際的大海上進行艦隊搏殺！但其實在表面的鬥志昂揚之下，發動機的熱效率同樣關乎著從武器裝備載具到尋常家用交通工具的重要屬性！

一臺發動機的功率往往是需要給油來產生的。前面我們探討過了，動力不會憑空出現的，一切強勁的動力其實根本源自於給了多少燃料。所以當需求的動力愈加強大時，其實只代表一件事：你必須要供應上足夠的大量燃油去給發動機消耗！這時如果一臺發動機的熱效率過低，就表示你需要供應更多的燃油才能夠產生出同樣的動力，並且其中的大部份其實是被無用的發熱散發掉了。如果我們能夠竭盡可能的善用巧思去改善發動機的效率，那麼對於民用與商用的需求來說，行駛同樣的距離將會消耗更少的燃料，也就是省錢，這可能也是大部份市井小民最在意的一件事。對於軍事用途來說，雖然在某種程度上，軍事用途往往表現的好像不差錢似的，只要能夠產生足夠的性能，這個錢嘩嘩的燒好像都不會心疼。然而其實事情也並不完全是這樣的，當軍用發動機的效率過低的時候，有時候耗油燒錢真的事小，但是影響戰機的航程這事情可就嚴重了！效率過低的發動機即便能靠著土豪般的吃油如喝水一樣產生強大推力，但過大的消耗量將會給戰機產生一個嚴重的問題：短腿，跑不遠，也就是續航里程不夠長。我想對於通曉各種軍事歷史與軍武的愛好者來說，短腿導致的戰場劣勢應該不需要再多解釋什麼了吧？

所以效率這件事情不管放在哪裡其實都是非常重要的性能指標， 一個效能高的引擎在直接上的意義意義就是， 能在提供相同動力輸出的前提下，比別人更加節省燃料的消耗； 或者在同樣的燃料消耗率之下，能提供比別人更多的動力輸出。 在民用用途上，省油的引擎可以節省燃料的消耗量，減少成本的支出，可以使運輸服務成本更加低廉，也可以減少廢棄排放，更加保護地球；而對於家裡的爸爸媽媽來說更加直觀的感受，可能就是能夠減少每個月從錢包裡掏出來給車子加油的鈔票數量；對於軍事用途來說，省油的引擎同樣能夠節省軍費的開支，即便是在花錢不手軟的戰爭行動中，省油的引擎能夠給予各種武器載具擁有更遠的作戰範圍，或者能夠滯留空中更久的時間。

省油？

還有一個和引擎效率有關，可能比較常見的混淆，就是「省油」與「效率」之間的關聯。

簡單說就是一個配備高效率引擎的車輛不一定省油，一個省油的車輛也不一定配備有高效率的引擎。其實可能會產生的混淆，在於「省油」這個詞往往與語境有關係，白話的意思就是不像是「效率」一詞具有比較嚴格的定義，其就是投入與產出的比例，而「省油」這個詞的意義則往往依賴於說出它的時候腦袋在想什麼有關。

比方說我們說一輛大巴士省油的時候，旁邊小朋友可能就會冒出疑惑了，明明看著這輛超大巴士嘩嘩的在燒油，我們加油一次一千元，他們加油一次一萬元，怎麼就省了呢？我想小朋友說這話的問題在哪裡，大人們應該都很看得名白。雖然人家大巴士看起來燒油燒很兇，但是人家的動力需求也大呀，一次可以拉 100 人出去，平均下來一趟路一個人才花 100 油費；我們加 1000 油錢看似不多，但一趟路只能拉 4 人，分下來一個人花 250 油費呢！因此從這個例子來看，如果撇除掉大小車輛呆重的影響因素的話，那麼這輛大巴士搭載的發動機很可能就比那量小車的引擎具有更高的能量轉化效率。 (然而事實上大車小車造成此等差距的主因可能還是來自於車輛呆重的差異，不過本篇的重點不在此，所以就姑且當作大巴士的引擎比較高效吧。) 在這種情況下，我們一般認為大巴士會比較省油，因為如果要用小車同樣運送 100 人，油費就會是 25000，肯定是費油的！

上面的例子很符合效率與省油之間的關聯性直覺，那麼我們再看另一個例子。今天我想出去散散心晃兩圈，這時我應該要開大巴士出門呢？還是開小車出門呢？延續上面的設定，這時如果你開大巴士出門就肯定費油了！因為大巴士引擎的功率大，即便能量轉換效率比另一輛小車高，但如果只看燃油耗用量的話，肯定還是比小車消耗的多的。所以在這樣的前後文語境下，我們一般會認為小車比大車省油；甚至如果有摩托車能夠作為選項的話，還能比小汽車更省，即便這臺小摩托引擎的能量轉換效率可能比其他二者都還更低！

所以，我們平常也許沒有意識到，但其實「省油」這個詞作為口與的描述詞，它的意義其實很依賴談話時的上下文、或需求的情況，而這也給我們提供了另一個設計產品時的想法。為了省油，除了一個勁的開發上各種神奇科技去提升引擎的熱效率之外， 直接減少發動機的功率輸出，往往能夠省下也許更加可觀的燃油消耗。這就是為什麼現代的汽車一個個都在縮減汽缸數量的原因，也是那些看起來很厲害的大功率發動機在民用市場不見得更加吃香的原因其一，因為如果客戶的需求並不需要那麼大的馬力的供應的話，直接縮減發動機功率也能夠非常有效的降低對燃料的消耗。

功率與效率總結

至此，我們應該了解了功率和效率這兩項屬性對於一臺發動機的重要價值。那麼理想上，我們肯定是要一個功率超高、效率也同樣超好的一部發動機呀！可惜在現實世界裡，也不知道是上帝喜歡和人類開玩笑還是怎麼樣？你會發現這兩項指標通常難以兩全！在體量差不多規模的發動機上， 一部效率高的發動機，往往它能產生的功率就不會大； 相對的如果一部發動機能輸出大功率，那麼往往它的效率就高不起來。 比方說目前人類世界上輸出功率最大的動力系統大概是火箭了吧，它能把幾十上百噸的酬載加速到 280000 km/hr 的速度送入太空，然而它的效率一般卻可能只有大約 2% 到 4% 左右；而像是燃料電池、離子火箭這種高效率的東西，它們產生的功率卻一個比一個還小。當然你也可以把高效率的發動機造的大一點，這樣它就又高效又能大功率；只不過它的體積和重量也就一起往上去了……

當然前面只是講一個大概的趨勢，就如同我們用汽缸數量去粗略評估一臺發動機的馬力一樣，只是一個非常粗略的趨勢關係而已。實際上在核心原理相同的發動機類型裡，每一個不同設計之間仍然存在著彼此之間的優劣競爭的。而且目前為止我只有大範圍抽象式的表達了功率和效率兩難的一個現象，並未深入解釋其中的原因，不過在未來我們更加深入探討發動機的效率分析、以及往後的其它發動機主題文章裡，慢慢都會一一展現出造成這些兩難情況的詳細原理。總之一般來說發動機的效率和功率往往是個不能夠兼顧的性能屬性，而更多的思考與設計理念往往是在兩者之間做一個怎麼樣的折衷取捨的策略佈局。

最後講到功率上限這件事。從前面的示意圖來看其實看不出來發動機的輸出功率上限這回事，那是因為我們將發動機視作一個黑盒子，左邊投入燃料給它吃，右邊它就會產出動力。然而實際上這個黑盒子內部的實現原理決定了很多表面特性，比方說以汽缸、活塞為原理基礎的發動機就存在一個比較明顯的發展瓶頸：動力有個上限並且難以突破，這個我們在往後的篇章會更深入探討。簡單的說就是，有些發動機的原理結構導致了它胃口不大，即便理論上依據黑盒子理論，好像只要塞給它更多的燃料就能夠產生更多的功率，然而現實上發動機卻會告訴你它這小嘴吃不下了！這時你想塞給它更多的燃料，然而它卻消化不了；那麼當燃料消耗的速度有個上限的時候，依據本篇學到的黑盒子原理，我們也能很容易的得出一個結論： 發動機的功率最高只能達到某一個程度為止！

結尾

本篇我們試著使用小學生能夠理解的程度介紹認識了燃油發動機的兩項重要性能指標：功率與效率，從黑盒子轉換機器理論的角度去重新理解發動機的角色，認識能量轉換率與廢熱的生成，認識功率與效率所代表的意義，以及初探兩者之間的關聯性和限制。下一篇我將進一步分析活塞發動機，用更加實際可見的物理和數學原理去計算輸出功率、及轉換效率，使讀者在本篇可能過度抽象描述的性能特性之後，可以透過更加實際的計算去理解背後的物理原理。

1. FreeImages

活塞引擎 6：機件振動實例

Mon, 23 Sep 2024 20:35:12 +0800

上一篇 ^[1] 介紹了機件運動導致振動的原理，也介紹了我做的一個用來分析活塞引擎振動趨勢的小程式，而這一篇我就要用它來挑選分析一些實例，一窺各種常見構型引擎的振動特性。

由於要分析的種類數量有些龐大，為了儘可能減少不必要的版面複雜性，我並不會張貼每個測試案例的所有結果。不過如果讀者有興趣參考的話，本文的所有測試結果、分析圖、和所使用的參數、以及所使用的分析程式 ^[2] 都已打包，有需要的讀者可以自行下載分析驗證。

如果你還沒有閱讀過前篇^[1] 的介紹的話，建議先過去讀過之後再來閱讀本篇，因為除了程式的用法和原理介紹以外，前篇也做了有關參考座標系和圖表意義的說明，在缺乏這些認知前提的情況下，可能會比較難讀懂本篇的內容。

另外，本篇可能會在某個個別的案例解說時歸納一些通用的特性，這些特性往往是在很多具有特定特徵的其他配置會共同顯現的特徵，這些歸納的重點會以粗體標示，相當建議在閱讀的時候特別注意。因為本篇分析的案例較多，因此許多因為共同特徵所產生的特性和對應方法等通常就不會一直重複敘述了！

那麼首先，我們先從複習前篇的單缸引擎振動特性作為開始：

單缸

基本單缸

可看到結果顯示在 Y 方向上的振動趨勢挺大，力變化幅度達到 193 牛，主要的原因就是因為這是活塞的運動方向。相對的 X 方向的力變化幅度明顯小得多，只有約 46 牛，主要是由於連桿的運動所產生；另外 Z 軸達 0.46 牛米的轉動力矩變化也同樣是因為連桿的運動所產生。

在這個案例裡，我給曲柄(或曲軸，因為只有單缸，所以配重歸屬於何者都沒問題)加上了一點點的偏心量，用意是在不嚴重影響總體結果的情況下，能讓人看出偏心曲軸在整體力變化分佈中所扮演的角色。在 Y 方向的力分佈圖中還有一點值得特別注意：活塞所產生的力變化趨勢並不是上下對稱的！這點特性在後面其它的案例分析中是個很重要的部份，也是導致在有些看似能產生上下力相消的情況中，實際上卻不能完全相消的最主要原因。

總體而言，單缸型態的振動大這件事其實也沒什麼好意外的，畢竟它就只有一個汽缸而已！所以單缸引擎在本篇可能最大的作用是用來給其它型態引擎作為對比吧。

加入曲柄(曲軸)配重

從前面的測試結果中，我們能發現偏心曲軸的力趨勢正好和活塞與連桿的趨勢相反，這就產生了一個想法：我們能不能增加曲軸的偏心配重，用來抵消活塞與連桿所產生的力？

有關曲柄配重的部份，我在前篇^[1] 已經解釋過了，這裡就不再贅述，直接看結果。從結果可以看到在 X 方向上，曲柄配重直接完美相消了連桿產生的作用力；在 Y 方向上顯然也有正向縮小作用力的效果，只是削減的力道顯然是寥勝於無；在 Z 軸的轉動力矩上則矯枉過正，雖是有抵消連桿力矩的效果，但消完後剩下的力矩反而比連桿原本產生的更大，差不多是原來的 3 倍！

總結而言，適量增加的曲柄配重可以完美消除活塞連桿在橫向上的作用力。這一點結果很重要，且在後續的案例中都會有所應用，後面就不再重複贅述。另外一個比較實際的情況是：其實在曲軸方向上(也就是 Z 軸)的轉動擾動比較不是那麼受注目，因為活塞引擎的動力輸出本就是不連貫的，而且汽缸愈少愈不連貫，其本身就會在曲軸的轉動上產生不小的擾動。因此對於機件運動在曲軸上造成的轉動擾動來說，只要擾動不要過大，一般就不會太過在意！

此外，曲軸配重的配平效果也同樣輔證了一般討論直列發動機振動時，多只談論活塞上下運動所造成的振動的合理性。如果忽略或不在乎曲軸方向的轉動擾動的話，在活塞連桿橫向影響可以被完全消除的情況下，綜合前篇解說過的活塞連桿^[1] 作用力特性，就可以將活塞和連桿視為一個整體，那麼這樣的簡化分析方法便也是非常簡單實用的了！

嘗試使用更多配重

有了前面關於曲柄配重的試驗結果，我們不妨再試試看更加激進的策略會產生什麼樣的效果？既然原來的曲柄配重對於活塞運動方向的力相消沒什麼太大作用，那這裡就嘗試再加入更多的曲柄配重。

本例試驗將曲柄的配重增加到將近原本的 3 倍，可見到在原本振動趨勢最大的 Y 方向上，我們將作用力的變化範圍縮小了 37%，效果算是還不錯了。當然這麼做的缺點也很明顯，它會在 X 方向上產生振動源。本例所挑選的配重特別控制使 X 方向上的振動趨勢與原本相近，不過若在應用上可以接受 X 方向更大的振動趨勢的話，就可以動用更大的配重，去消減 Y 方向的振動趨勢。此外除了 X、Y 兩個方向之外，本方案在 Z 軸產生的轉矩趨勢是基本單缸配置的 6 倍多，是加入了基本適當配重方案的約 2 倍。

總結而言，使用增加曲柄或曲軸配重的方式可以一定程度的消減最大的振動源，也就是活塞運動方向的振動，不過副作用是會增加在其它方向的振動趨勢。造成這現象的根本原因，其實就是因為最大的振動源在活塞的運動方向，是在一條直線上，可是偏心軸所產生的作用力卻是成圓周輻射的，因此在削減某個方向的作用力之餘，也不可避免的在其它方向產生了更多的作用力。在實務應用上如果能夠接受平均力度較小但較多雜亂方向的振動的話，那麼使用曲柄或曲軸配重的方案就是挺實用的，他可以以雜項振動源的增加作為副作用和代價，來削減振幅最大的那個振動源。

雙缸

Figure 1. 雙缸引擎的數種運作組合 ^[3]

運動平衡

一般雙缸併排的情況，當然是兩個汽缸動作相反，一個上就一個下，這樣最合適不過了啊！只不過如同前面已經描述過的原因，兩個汽缸一上一下相反方向運動的時候，作用力其實並不能夠完全相消，如結果圖所示，在 Y 方向這麼一消減之後仍然剩下了 109.6 牛的振動源。而因為汽缸一上一下，所以還產生了 X 軸向上的轉動振動源約 6.2 牛米。不過畢竟只有兩個汽缸，這點副作用也是比較難避免的！

雖然 Y 方向(也就是活塞運動方向)的作用力只消減了大約一半的幅度，但是請注意到圖表，它的振動頻率增加了！這點現象很重要，雖然我們只能看到機件的作用力表現而不是實際的振動表現，但是只分析作用力的分佈這件事之所以有價值，就是因為在大半情況下它能直接反應實務的振動特性。而若說到振動，一般頻率愈高的振動肯定是幅度愈小的(除非恰巧逮到共振)。在生活上其實常能見到這樣的例子，比方說我們在用洗衣機給衣服脫水的時候，我們的衣服當然不可能放的平均完美，當然會有多或少的質量偏心，於是在脫水剛啟動時轉速還不快的時候，就能感受到這時的振動是最大的，有些情況下如果我們不壓住洗衣機的話，洗衣機甚至會移位！但是當洗衣機的滾筒轉速快起來以後，振動反而就小了，洗衣機也趨於穩定安定而不再需要我們操心了，直到脫水結束要減速下來的時候，才會讓振動再次大起來……

這麼個故事告訴我們什麼事呢？那就是即便是同樣的作用力，如果它的作用頻率高，那麼通常所造成的實際振動會更小！ 至於實際多小？什麼時候是通常，什麼時候是不通常？等等這些要想弄清楚的話，還是得去做更深入的振動模擬計算才行了！回到這個案例，一般來說汽缸一上一下的行程正好對應曲軸轉一圈，所以如果曲軸轉速是 10 RPM 的話，那麼活塞就會在一分鐘之內上下 10 次，如果只有一個汽缸的話，那麼抓著這個引擎的你也會感覺到它上下動了 10 次；但若是本案的兩活塞引擎的話，同樣一分鐘轉 10 圈，你卻會感覺到它上下動了 20 次；假設單缸引擎轉速 10000 RPM 的時候可以讓人幾乎感覺不到振動的話，那麼這樣的雙缸引擎卻可能只要 5000 RPM 就能辦到了 (就算不考慮其實雙缸的作用力也同時變少的話)。所以雖然雙缸配置在振幅也就是力的大小上只削減了大約一半，但是因為頻率變成兩倍，所以實際的振動情況通常會是非常顯著的變小！

至此我們再重新整理出一個通用規律： 通常來說，高頻率的力變化產生的實際振動表現會比較小，而低頻率的力變化產生的振動表現會比較大； 因此在觀察後續的力變分佈圖時，除了關注力變的大小變化幅度之外， 也要知道如果某種佈局能夠使力變的頻率增加的話，也能算是對振動的改善。

最終從機件運動導致振動的角度來看，這種雙缸的配置看起來雖然還是有不小的振動傾向，但是對比單缸的情況肯定是改善了非常多的。然而這種配置實際上卻還隱藏著一個很重要的缺點！如果從點火間隔的角度來看，因為四行程引擎是曲軸轉兩圈才完成一次循環，也就是轉兩圈才會點火一次，那麼本例的配置就會導致點火的間隔不平均。在本例中，曲軸轉完一圈就點了兩個汽缸，剩下的一圈則空著。所以在雙缸引擎的型態裡面來說，其實兩個活塞行程相差 180 度所產生的機件振動是最小的；但副作用就是會因為點火間隔的不平均，反而產生動力卡頓不連貫感！

點火平衡

如果說前例的配置會因為點火間隔的不平均而產生劣勢，那麼調整讓點火順序平均如何？然而很不幸的，我們再複習一下，四行程引擎是曲軸兩圈一個循環，也就是要在兩圈 720 度的行程內點過一遍全部的汽缸，而我們的汽缸只有兩個，所以平均就 360 度點燃一個汽缸。疑！這 360 度可不就是整整一圈嗎？於是這麼樣的條件一套下來以後，就會發現要讓雙缸引擎平均點火的話，兩個汽缸就得要同上同下！

因此這樣的配置所帶來的缺點就不用多說了，兩個汽缸同上同下，所有特性與單缸一模一樣，不過振幅是原來的兩倍！

折衷平衡

雙缸引擎是個比較難兩全的情況，顧了機件振動就顧不了點火間隔，顧了點火間隔就顧不了機件振動。那麼能不能夠折衷處理呢？兩活塞的行程差 180 度時對機件運動最友好、行程差 360 度時對點火間隔最友好，那麼平均一下就會得到 270 度這個數字，於是雙缸 270 度的曲軸角就是這麼來的；當然，270 度和 90 度的說法其實是一樣的！

在折衷平衡方案之下，振動趨勢的各方面結果表現，也是居於完全平衡配置和完全不平衡配置二者之間。

直列 3 缸

雙缸和三缸在直列引擎裡面其實是蠻重要的基礎對照組，所以我更完整的把加了曲柄配重、和沒有曲柄配重的方案都做了一遍。這麼做的目的，主要是為了在目前配置還沒有那麼複雜的時候預先做個對照。至於到後面更複雜的案例我就不會放過多的計算結果了，會直接討論最佳配置的情況。

無連桿平衡配重

首先注意到，三缸機在橫向位移(X、Y 方向)的振動趨勢上可以達到非常完美的平衡，而這是雙缸機所達不到的！究其原因，雙缸機的兩個活塞一上一下反向運動，然而活塞的上下運動其實是不對稱的，所以只削減了大約四成，並不能完全對消互相的作用力。而三缸機則是另一個路子，三個活塞的行程各偏移了 120 度(1/3 圈)，反而因此可以互相完全消除彼此的作用；而雙缸機之所以不能，其實從圖形來看，就是因為活塞行程偏移了 180 度(1/2 圈)，正好是波峰波谷距離(180 度)的整數倍，剛好不能相消。

至此我們可以整理出一個重要的結論： 活塞運動的相位差不為 1/2 (圈)的整數倍時，可以完美平衡彼此的橫向位移力作用(力矩是另一回事)；而活塞運動的相位差可被 1/2 (圈)整除時，會剩餘橫向的力變化導致振動趨勢。精簡一下其實可以得到一個更加簡單的結論： 在曲軸上分割出來的，角度相異的曲柄數量為單數時，橫向作用力可完全互相抵消； 而這個曲柄數量為雙數時，不能完全相互抵消！ (這裡強調「角度相異的曲柄」，是考慮到後面有些曲柄數量看似很多，但其實有部份曲柄是朝向同一個角度的情況，所以提前為此下的限制。)

研究完橫向作用力的影響之後，接下來看看彎曲力矩的影響。從結果可以看出，雙缸和三缸在 X、Y 軸上的力矩都不平衡，簡單理解就是引擎可能不會上下左右振，但是會搖起來！雙缸很好理解，兩個活塞在質心的兩邊，運動方向相反，當然就會造成轉矩。而三缸的情況(其實所有直列單數汽缸的配置都有此共同現象)，剛好最中間一個活塞在正中央，所以它基本產生不了轉動力矩，可以忽略不計，力矩平衡主要要看兩側其它汽缸的作用；然而兩側活塞要不就因為相位差整除不了一個圓周、要不就是因為活塞上下行程不對稱的緣故而無法互相完全抵消，總之一定會剩下多餘的轉動力矩，產生轉動方向的振動源！至此我們又得出一個結論： 直列引擎的汽缸數量為單數時，一定會產生旋轉方向的振動趨勢；至於汽缸數量為雙數時則不一定，得再進一步分析。

最後特別看看 Z 軸，也就是曲軸同向的力矩分佈，可以觀察到三缸機會產生微小幅度的轉動振動趨勢。三個汽缸組件在 Z 方向上產生的力矩分佈雖然是很漂亮的對稱形狀，但是與活塞的情況不同，在相位差不為 1/2 (圈)整除時反而會餘下殘存的力矩；對比雙缸(機件平衡的那個配置)的分析結果，相位差為 1/2 (圈)整數倍時反能完全相消 Z 軸的轉動力矩！這樣又能整理出一個結論： 當曲軸異角曲柄數量為單數時，必然會在 Z 軸上產生轉動振動源，雖然振幅可能並不大； 而這個曲柄數量為雙數時，則可完全消除 Z 軸上的轉動力矩。

但是如同前面解釋過的，Z 軸向的振動趨勢其實實務上可能影響被排在最末位，一來是因為通常它產生的振動幅度本來就小，而且頻率還比較高，在曲軸一圈內進行了上下三個週期，套用我們先前的結論，更高頻的振動通常會讓實際表現出來的振動效果更小。再來是因為在引擎軸的旋轉方向上可能存在其它更大的振動源影響下 (比方三缸機的點火膨脹週期就是不連續的)，使得機件所造成的 Z 軸旋轉擾動的存在感比較低。

加入連桿平衡配重

這個測試與前一個三缸配置基本完全相同，差別只在曲柄配重而已。前一個配置為標準曲柄配重，就是配重只平衡了曲柄它自己而已，而這一個配置則增加了更多配重，試圖配平活塞連桿所產生的力作用。

簡單瀏覽結果，會發現所有的振動特性基本維持不便，只差在轉動方向的振動趨勢上。其中 X 軸向的轉動振動趨勢(也就是側視引擎時的轉動趨勢)削減了 20%，只剩下 12.6 牛米變化量，而 Y 軸向方向的轉動振動(也就是俯視引擎時的轉動趨勢)則被完全消除！至此能讓我們意識到曲柄配重在整個引擎的振動平衡性裡面所佔據的重要性， 曲柄配重在直列多缸引擎上的主要作用， 其實在於抵消因為活塞連桿的橫向作用力而產生的 Y 方向力矩；其次則是能稍微消減 X 方向的力矩，只不過杯水車薪，X 方向主要還是得看活塞能否互相平衡。

直列 4 缸

平面曲軸

直列四缸的各方面表現大多都很傑出，各方向轉動力矩完全平衡，並且雙數汽缸的特性使它並不需要多餘的曲柄配重就能達到轉矩平衡。平面位移震動趨勢上，X 方向作用力完全平衡，唯一的缺點就是在 Y 方向的振動趨勢削減效果並不好，在測試案例中仍有約 219 牛的力變化！

仔細觀察四根曲柄的角度會發現，曲柄其實兩兩方向一致，因此實際上在橫向力的作用上與雙缸機一致，會在 Y 方向剩餘這麼多的作用力也就不奇怪了。究其原因其實就是四個曲柄要去平分四行程整個行程的 720 度，這麼分下來的角度差就是 180 度了，正好兩兩同向。像這樣的現象在後面其它更多汽缸的配置上還會再看到， 因為能整除 720 度的關係，直列雙數汽缸時，曲柄角度總是兩兩同向成對， 使得在橫向的振動特性上與只有汽缸數量一半的配置相同！

再觀察曲軸曲柄的角度分佈，還會發現四缸的曲軸其實就是將雙缸曲軸給對頭接起來而已，而這其實就是在點火順序的排佈、以及曲柄平均分割曲軸角度之下所產生的自然結果。然而在後面其它更多汽缸的配置其實也都會觀察到這一個共同現象，因此我們預先整理出一個結論： 在大多數的直列雙數缸情況下，其實可以從中間對半分割， 而其左右兩邊正好都會是鏡像對稱的、汽缸數只有一半的兩個發動機的組合。

當然前面的歸納符合大多數通常情況下的觀察結論，而在實務上，如果你就因為我這麼說了這句話，就想要卯起來設計一個不鏡像對稱的配置，也不是不能做到的；只是稍微試一下你就會發現，如果要顧及點火順序平均亂散的話，曲軸很自然就會長成這個鏡像對稱的樣子，如果硬要做成鏡像不對稱則多半會發現它的點火分佈也不太平均。那麼這個其實並不會被肯定遵循的歸納結論對我們有什麼用處呢？我覺得它的最大好處在於可以簡化我們對分析結果的「理解」。 (當然這並不會去影響實際的物理分析結果，只是影響了在腦袋思考理解的層面上對我們的簡化幫助)

在符合前述規律的引擎配置上，我們可以將一個汽缸很多的直列引擎去直接套用汽缸數量只有一半的分析結果，例如本案例的四缸引擎就可以等效為兩個對稱雙缸，可以直接套用雙缸的分析結果來理解它。在橫向的平移振動趨勢上，本例四缸發動機完全就等同於對半的雙缸機，只不過幅度被乘為兩倍；而在轉動的力矩部份，成對的兩個雙缸機正好對稱的、等幅的對消了彼此的力矩作用，因此得到了非常良好平衡的力矩振動表現。其實在後面的實例分析中我們也能發現： 直列雙數缸配置往往能夠做到幾乎不存在轉矩上的振動趨勢！

十字曲軸

前面分析的四缸曲軸，因為曲柄角度差都是 180 度，組合起來正好左右展開，好像可以直接放平在桌面上(如果曲柄配重不要凸起來的話)，因此前面這種曲軸常被稱為是「平面曲軸」。

前面的平面曲軸配置結果告訴我們，雖然它在各方面表現都不錯，就是 Y 方向的振動表現不太好；那如果我們把曲軸的角度分割的更細呢？於是這就產生了一種將曲軸角度全部平均分割的特別款曲軸，四個曲柄平均角度差為 90 度，從軸向看過去正好是個十字形(或者斜一點看就變 X 形)，所以就被稱為「十字曲軸」，即為本測試案例所使用的設定配置。

前面才剛提過一個歸納結論：直列雙數缸配置多半可以從中間對分為兩個鏡像對稱的兩個較小的配置。也說明過這只是一個符合一般情況的歸納結論，並不是不能夠設計個就是不鏡像對稱的東西；你看本例馬上就給你出了個這樣的例子，這十字曲軸就是不鏡像對稱的案例。從結果可以看到，雖然因為四缸相位差仍然可被 1/2 圈整除，但是因為活塞行程被分割的更細密，所以位移振動的相消結果非常良好，在 Y 方向只剩下 7.6 牛的變化範圍，約只有平面曲軸版的 3.5%。只不過它的轉矩振動表現就不太理想了，甚至 X 軸向有 26 牛米的力矩差距，這方面表現比三缸機還差！究其原因會發現，十字曲軸它並沒有鏡像對稱，因此沒能像鏡像對稱的配置那樣良好的消減轉矩振動。總結下來可以說，十字曲軸對於降低位移振動很有幫助，但是以產生轉矩振動的副作用作為代價的。

此外十字曲軸所付出的副作用並不僅止於此。由於四缸 90 度的行程差並沒能夠平均分割整個 720 度的行程，因此不可避免的帶來點火間隔不平均的現象。以平面曲軸來說，曲軸每轉動 180 度就點火一個汽缸，4 次點火正好平均分配 720 度；而十字曲軸的配置下，會有兩組汽缸間相距 90 度就點火，只有平均間隔的一半，另外兩組汽缸則會間隔 270 度點火，比平均間隔多了一半。當然這樣的點火不平均現象雖然在理論上並不完美，不過也有人喜歡這樣的配置所產生的引擎聲浪、以及它帶來的動力頓挫感，這方面就不予置評了。

直列 5 缸

五缸機的汽缸數量為單數，首先我們就知道它的曲柄配重省不了，然後再看它表現出來的振動趨勢，與同為單數汽缸的三缸機特性基本完全相同。細節來看，五缸和三缸的 X 軸向轉矩振動是半斤八兩，但是在 Z 軸方向轉矩振動幾乎已被消為零，Y 方向平移振動也是已經幾乎為零，這方面比三缸機更加傑出。

總結而言，五缸機的振動特性基本可以比照三缸機。細節方面各有優劣，但整體差異不大，更大的差異可能是五缸機因為汽缸數量比較多，所以馬力更大吧！

直列 6 缸

看了前面這麼多直列引擎之後，我們應該已經得到兩點簡單結論：雙數汽缸除了 Y 方向的平移振動以外，其它方面幾乎沒有振動趨勢；單數汽缸除了 X 方向轉矩振動外，其它方面幾乎沒有振動趨勢。這麼就產生了一種想法：能不能拿兩個小的單數缸機，鏡像對稱合併成一個大的偶數缸機，把單數機的轉矩都對消掉，變成一個在各方向幾乎都沒有振動的完美引擎呢？這個方法是真實可行的，我們用一個最小型的單數機 — 也就是三缸機，把它鏡像拼起來就成了經典的直列六缸機了！

觀看六缸機的各方面振動趨勢，全方面幾乎都被內部相消，合併起來都幾乎為零！真的要刁鑽的話，它其實還在 Y 方向、和 Z 軸向殘留了一點點的剩餘，不過數值大小都已經到了小數位了。因為六缸的穩定性表現幾乎達到完全完美的程度，也就不難了解為什麼那些研究汽車引擎的人都會這麼推崇直列六缸了！

不過在一般民用車輛上不常見直列六缸，也倒不是什麼別的原因，單純就是因為一：六缸機稍嫌太長了；二：六缸機汽缸數量太多，已經大大超過一般民用對於馬力的需求。但是在飛機上就沒有這些限制，所以航空飛機就非常的愛用六缸機(其實正確來說是直六的變體：V12)。

直列 8 缸

同前面的論述，直列八缸就是兩個鏡像對稱的四缸機合併起來的結果，只不過我們選用的是平移振動表現更加的十字曲軸四缸機；至於十字曲軸帶來的轉矩振動？這點倒完全無需要擔心，因為鏡像合併後自然能將這些問題給對消掉。

看看分析出來的八缸機結果，也是完全符合我們的預期，大多數的平移和轉動振動都已互相抵銷為零，除了在 Y 方向還剩下 15 牛的力變化範圍以外，但幅度相比平面曲軸的四缸機只剩下 7%。

直列 10 缸

前面我們用兩個三缸機併出來一臺六缸機，各方面表現已經近乎完美，但還是剩下了一點點殘餘，對於強迫症患者來說或許可能無法接受。那麼能不能用同樣的路子來造出一個完美的發動機呢？這就來試試看！比三缸機再大一些的單數缸就是五缸機了，兩個五缸機併起來就得到一臺直列發動機的終極版本：直列十缸發動機。

觀看直列十缸機的分析結果，基本同直列六缸一摸一樣，但是更加完美。各個方向的振動力都被削減到小數兩三位以下了，基本就是零。很多人分析引擎的時候都會說直列六缸是最完美的型態，但是這裡我卻用實際的分析數據告訴你：直列六缸並不夠完美，直列十缸才是真正完美的發動機型態！

但是這就讓我們產生了一個疑問，既然直列十缸這麼完美，為什麼實際上卻反而幾乎就沒見過採用了直列十缸發動機被用在車上或飛機上呢？我想這個原因也不複雜，因為直列十缸實在是太長了！

一個過長的發動機，實用上最直接的問題就是放不放的下？如果連飛機都會嫌棄這樣的發動機，那就更不用說車子為什麼不用它了！除了佔用的空間大小之外，過長的發動機還存在結構上的問題。當我們看到一個在理論分析上能夠各種力完美對消的發動機時，要知道實際上這些內部對消的力是靠著曲軸和主機本體的結構強度來承受的，那麼當這些結構件過長的時候，就會給內部的應力承受力帶來更大的設計難度，和實際應用上的風險。

因此雖然直列十缸在理論上更加完美，但是其所帶來的其他副作用卻給人帶來更多的難題，再轉頭對比它相對於六缸機所提供的改善程度，也就不難理解為什麼設計師們舉起手來掂量掂量之後，紛紛都拋棄十缸機而撿起六缸機了！

V 型 12 缸

有了前面直列發動機的分析基礎後，接下來要看的就是直列的變體：V 型發動機。首先先從最簡單單純的 V12 開始。 V12 其實就是將兩部直六給併起來的結果，因為直列六缸機本身就已經擁有非常良好的低振動性能，因此直接把它們合併起來也就沒有什麼難度，而從 V12 的分析結果來看也可以印證這點。

那麼這裡就提一個有點意思的小知識，V 型發動機的兩排汽缸的夾角為什麼總是特定的角度？其實這就是考量到點火間隔的平均性、以及曲軸曲柄角度分佈的平均性的結果。 12 汽缸要平均分割 720 度的行程的話，那就是曲軸每轉動 60 度就要點火一個汽缸，因此兩排汽缸的夾角最好就是 60 度，或著是 60 度的整數倍，比方說 30 度或 120 度 (不過 120 太寬了，基本是沒人會這麼做)。汽缸夾角正好是行程分割角度的整數倍時有一個好處，那就是能讓曲柄在曲軸上呈獻平均張開的形狀；如果你非要造一個夾角 40 度或 80 度的 V12 發動機也並不是不允許，只是這麼一佈置下來就會發現曲柄的角度分割會變得不太平均，自然也就對振動表現不利了。在本測試案例中，汽缸的夾角即選用 60 度。

V 型 6 缸

我們已經知道直列六缸、或者 V 型 12 缸發動機什麼都好，就是有兩個缺點：發動機用在車輛上有點過長的問題，以及對沒那麼大馬力的應用需求來說汽缸數量過多。因此雖然它這麼完美，但人們總是想要尋找汽缸數量更低的替換方案！

那麼我們將 V12 的長度折一半，就成了兩個三缸機組成的一臺 V6 引擎。 V6 的總體振動表現與直列三缸較為接近，但比它稍差些，可能是因為三缸本身就會產生些轉動力矩，兩臺以不同角度疊加起來之後，讓它在多方向的振動特性上更加複雜凌亂了吧！

V 型 8 缸

V8 引擎就是夾在 V6 與 V12 中間的型態，汽缸數量比 V6 更多，但尺寸長度比 V12 更小。不過 V8 引擎絕對不是把 V6 和 V12 加起來砍半這麼簡單而已，事實上我在製做這個案例模擬的時候遇到最多難題的案例就是在 V8 的配置上！

V8 就是兩臺直列四缸拼在一起沒錯，並且經過前面的計算原理可以得知，兩排汽缸的夾角 90 度應該是個不錯的選擇。但是實際排佈一下曲軸曲柄角度後就會發現一個神奇的現象：在安排平均、對稱的點燃所有汽缸的情況下，八個曲柄很自然的形成各自夾角 180 度，也就是變成一個八曲柄的平面曲軸！這種曲軸長相顯然對振動表現會有較差的影響，得改，但怎麼改呢？理想的情況應該要至少產生一個像是十字曲軸那樣的東西，才能在各方面比較平衡，但是如果要顧到行程順序平均平衡的話，我排了好久竟然排不出來！後來我上網偷看一下別人的答案，這才發現原來是真的沒法完美的排出美好的形狀。當然現行流通的 V8 引擎顯然用的絕對不會是平面曲軸，那麼他們是怎麼做到這一切的呢？原來秘訣在於犧牲一些點火順序上的均勻性。

一般來說 V 型就是兩個直列汽缸，兩排汽缸各自按照各自的點火順序點火，然後兩排汽缸之間再彼此很平均的左、右、左、右這樣交錯點火。而到了 V8 引擎上，為了曲軸角度的排佈關係，兩排汽缸之間的順序就變得不是那麼平均交換關係，而是變成了左、右、左、左、右、左、右、右這樣的順序。

總體而言，V8 的振動表現比較接近使用了十字曲軸的直列四缸機，但比其再稍差些！

水平對臥 4 缸

水平對臥配置可以算得上是 V 型配置的特例，即 V 型佈局的夾角為 180 度的時候即是，然而光是這麼的看待水平對臥佈局還是顯得有些太粗淺。水平對臥並不僅僅只是兩排汽缸夾角 180 度而已，我們從上面的配置分佈圖可以視覺化的看到，它一個更重要的特點在於兩排汽缸的曲柄是完全鏡像對稱的！

在這麼特別情境下使用的如此曲柄角度分佈，給水平對臥發動機帶來一項極為特殊的特性：它左右兩邊的汽缸運動完全對稱！在討論雙缸和四缸機的時候能發現一件事情，雖然看似兩個活塞一上一下的成對運動，但它們並不能夠完全對消彼此的作用力，因為活塞上下半部的運動並不是對稱的。而到了水平對臥這邊，當左邊活塞往外走時，右邊活塞也在往外走；當左邊活塞往內走時，右邊活塞亦是。並且它們的運動行程位置也是一致的，當左邊活塞在靠近上死點範圍快速移動時，右邊也是；而當左邊運作在靠近下死點範圍較慢運動時，右邊亦同。唯一的缺點在於 Y 軸向殘餘了微幅的轉矩振動源，這主要是因為活塞連桿和曲柄本身存在厚度，所以左右汽缸其實並不能夠完全對準一條線，而必須在 Z 軸方向稍微拉開一點點的距離所導致。

總體來說，就是這樣子近乎左右完全對稱的活塞運動行程，使得水平對臥機可以不受「1/2 圈整除」魔咒的影響，總是能夠保持力平衡。雖然說關於運動平衡這件事並不是水平對臥機的特權，我們也已經知道直列式和 V 型排佈同樣也都能夠達到完美平衡狀態；只是相比於後者需要 6 缸、12 缸以上才能達到完全平衡，水平對臥機的更大優勢在於可以使用非常少的汽缸數量就能達到非常良好的平衡效果，因此水平對臥式佈局就成為了在較低排氣量的應用用途上具有獨特優勢的存在。

水平對臥 6 缸

水平對臥 6 缸機雖然也是擁有水平對臥機獨特的對稱曲軸，但是從結果來看顯然表現就差了不少！這主要是因為它的左右兩半是個三缸機，而三缸機本來就存在一些沒能被平衡的力矩，從而導致水平對臥 6 缸機表現出多個方向的雜項振動源出來。

水平對臥 8 缸

水平對臥 8 缸機又回復了 4 缸型態所擁有的近乎完美的平衡狀態。至此我們能給水平對臥式佈局總結一個簡單的結論： 水平對臥式佈局，必須要在單邊汽缸數量仍為偶數時，才能達到近乎完美的振動平衡！

星型 5 缸

星型發動機表面上看應該要是一個極度偏斜不平衡的構型才對，然而計算模擬的結果卻表現出非常良好的振動表現，這是怎麼一回事呢？

不同於在其他的配置上我們總能夠精心配置每一個曲柄的角度位置，單列星型發動機全部汽缸只共用一個曲柄，因此相鄰活塞的運動是極其協調相似的，照理來說應該會是振的最厲害的佈局。然而星型佈局有一個特點，就是它的活塞和汽缸是輻射狀排佈的，這項重要的特性使得曲軸配重在這裡能夠發揮出非常有效的作用！

回顧最初我們在單缸引擎上試圖利用曲軸配重平衡活塞運動所做的嘗試，在那個案例中之所以效用不佳，就是因為活塞產生的作用力是一個方向的，可是曲軸的作用力是圓周輻射分佈的，就導致這邊力縮小了、那邊力卻放大了的問題。但是在星型佈局上就不一樣了，環繞了一圈的活塞使得它綜合的作用力也同樣是圓周輻射分佈的，加上發動機質量中心點正好就在曲軸軸心上，因此曲軸配重可以非常完美的平衡掉活塞運動本來應該產生的非常不平衡的作用力。以上的論述內容都可以在分析結果圖的趨勢變化中看見這項理論的合理性，並且實際的數字也印證了它的最終效果。

好了，道理是這個道理，但是從計算出來的結果來看感覺好像也沒有那麼的完美。機件作用力互相削減之後，橫向位移作用力部份還剩下了 4.8 牛的力變化量，雖然確實是有不錯的削減效果，但是對比前面的其他形式發動機好像也沒有特別優秀，這是怎麼回事呢？其實簡單的來說就是汽缸數量太少了。偏心曲軸所產生的力量是隨著曲軸的轉動而非常均勻平滑的沿著圓周方向作用出去，但是個別的活塞連桿卻是在同一個軸心角度的位置上產生作用力，兩者自然是沒有辦法完全對應匹配，這有點像是在數位圖片相關話題上常說的「解析度不足」。如果讀者有興趣自己玩玩三缸星型配置的話，應該會能更明顯的觀察出這個現象 (但我實在是暫沒有心力去跑更多的測案了)。如果前面的這個道理是對的，那麼只要汽缸數量愈多，活塞在軸心圓周上的分佈就會愈細密，越發接近連續分佈，也就會能夠更好的與偏心曲軸所產生的作用力完美對消；而事實上後面汽缸數量更多的星型佈局測案會證實這個現象。

星型 7 缸

星型 7 缸的結果表現特性與 5 缸基本完全一致，但是幅度更小，橫向只剩下 0.3 牛的力變化量，基本已經能將之忽略當作不存在了！

星型發動機與前面我們分析過的其它型式不同。在先前的汽缸佈局型式裡，往往多一顆、少一顆汽缸的結果表現可以展現出完全不同的特性，但是星型佈局就不是這樣。 星型佈局下不管有多少汽缸，它的振動表現特性是一樣的， 只差在作用力分割組合的細緻度、以及最終產生出來的合力大小幅度上。

星型 9 缸

既然在星型佈局已經分析出結論，理論上已無需要再多做更多的案例，但反正星型的汽缸數量就三個數字而已，於是就順變再跑個 9 缸的結果，也是作為一個對比和印證。

9 缸星型佈局的力組成特性果然與 5 缸、7 缸完全相同，而合力的大小已經達到小數三位以下，基本就是完全不存在！

複列星型 14 缸

既然經過前面的案例分析中我們已經知道並且證實，不同汽缸數的星型佈局振動趨勢是一模一樣的，那麼對於複列星型，我就不再分析過多的組合了 (不過在打包檔裡都有全部的案例分析資料 ^[2])，這裡就只以最常見的複列 14 缸作為本篇的壓軸結尾。

單列 7 缸的振動表現已經非常良好，只餘下了小數位的橫向振動源，那麼兩個相位相差 180 度組成的複列 14 缸就能夠完全對消彼此僅存的這一點點擾動源，使在各個方向上都不存在任何的振動因子。從分析結果來看，複列星型具有這麼良好優秀又穩定的性能表現，也就不奇怪為什麼在那個活塞發動機主宰的航空時代理，星型發動機能夠獲得這麼多用戶的愛用讚賞了！

結尾

其實在實際的產品上還存在很多很多其他的引擎佈置，比方說 V 型佈局其實還有一種也算是常見的佈置方式，就是兩排活塞共用曲柄的設計。比如一個 V6 引擎左右各三個汽缸，按照以往六個活塞要配上六個曲柄，但是在這卻只放了三個，因為成對的左右兩汽缸是共用一個曲柄。這麼設計的好處就是可以節省重量、微幅縮短引擎長度(因為曲柄本身也需要厚度)、並稍微減少製造維護難度和成本；當然副作用就是左右兩排汽缸各自的行程安排不再完全自由，而是會與對方互相遷就制約，振動表現自然不會最理想，也因此在這次的就沒有排入本篇的測試案例裡。

當然有關活塞引擎的配置還有很多很多各種各樣的種類和變化、亞型、或微調等等，只是礙於偏服不及、以及個人精力不及，就沒有去一一嘗試了。但是使用的工具和方法都留在這兩篇裡了，有興趣、有想法的讀者就可以自己弄下來玩一玩。這樣下次在和朋友聊天扯皮的時候就可以為自己多增加一些談資，至少下次再有人吹捧直六或 V12 有多麼完美的時候(其實是真的已經夠完美了)，你可以告訴他們真正能承擔完美稱呼寶座的其實是複列星型！ (或者其實你還可以把直十、V20 也拿出來掰扯一番！)

1. 活塞引擎 5：機件振動分析

2. 本文所有的案例分析資料、及分析程式

3. Straight-twin engine

活塞引擎 5：機件振動分析

Mon, 23 Sep 2024 00:16:31 +0800

前集說完了汽缸點火的順序影響引擎振動特性的部份，這集要來解說零件運動所造成的振動。

關於活塞發動機的振動特性，我並不是第一個提及的，只是在瀏覽了網路上的其他中文資料和節目後，覺得看到的解說都有些抽像而不夠具體具現。因此我就想，何不自己寫個小程式畫一下圖表，自己實際看看活塞、連桿這些東西的運動到底是如何推動引擎的呢？於是就有了這個小程式。

機件振動原理

Figure 1. 人在小船上往一方向走，船便往另一方向飄

實際的機器並不是像物理教科書上存在理想的完全剛體、或存在一個完全不會動的基點，當我們使一部份的結構動起來時，同樣也會導致連結這個零件的基坐本身發生位移。這就是牛頓反作用力的真實體現，就如同一個人在小船上起身往一個方向移動時，船本身會被推動往另一個方向飄走一樣。那如果船上的這個人他不是往一個方向一直走，而是來回走的話，那麼同樣也會導致他腳下的小船來回移動，而這可不就是振動嗎？回到活塞引擎裡面，活塞、活塞連桿、曲柄曲軸這麼來來回回的動來動去，這便是引擎振動的來源大宗，至於像凸輪軸這一類體量比例微幅的東西我們則一般忽略不計！

不過如果再進階一步想，其實「人往這移動、船往那裡飄」是說給小朋友容易理解用的，而實際產生振動的源頭其實是「力」的作用而不是「位移」，這會導致船隻的本體受力方向有時候會和一般讀者的直覺方向相反。比方說一個人雖然往船頭方向移動，可是他正在減速，這時候腳下的船受到的反作用力其實是向前的，與他的行進方向相同；而如果他在等速移動的話，船隻其實不受力。因此我們雖然可以透過機件運動的現象去計算振動的趨勢，但是注意我們關注的重點其實不是零件運動的位置，而是它移動的「加速度」！

最終整理一下，活塞引擎的機件運動導致振動是什麼意思呢？就是即便引擎不上汽油，不壓縮、不點火，僅僅只是用一個馬達插在引擎軸上旋轉起來，引擎也會產生振動；而這個振動的源頭不是來自壓縮、點火、或膨脹，僅僅只是因為零件運動之間的配平不平衡所導致的振動！

幾何和參數定義

現在要來介紹我所做的小分析程式 ^[1] 的用法。也許對於很多讀者來說可能並沒有時間精力去使用這隻程式，但是至少也絕對需要先了解一下我對它所做的座標定義，否則可能會不明白它跑出來的多張分析圖所表示的意義。

單一汽缸參數定義

Figure 2. 單一汽缸的和尺寸參數定義

為了化簡理解難度，這裡會將單一汽缸的參數定義、以及多汽缸聯合時的相關參數分開來講述，首先先來看看單一一個汽缸的情況(配置示意如 Figure 2)：

座標原點即為引擎的整體質量中心，無論是在單一汽缸的設定、或是在多汽缸的聯合設定中皆為如此，在自行修改使用時請注意這點。
零件運動的計算以曲軸軸心為中心，曲軸本身平行於 Z 軸，Z 軸以朝向紙面的上方為正向。而 Y 軸為紙面上方方向，X 軸為紙面右方方向。
由於曲軸可能並不在質心上，因此假定曲軸與質心(座標原點)之間存在一個距離為 Y-Offset 的移位，該值為正時表示曲軸在整體質心的上方，負值表示曲軸在質心下方。
汽缸中心線與 Y 軸具有一個夾角 Cylinder-Rad，不過在只分析單一汽缸的時候設定此值為零即可，此時汽缸中心線與 Y 軸重疊，方向向上。活塞只在汽缸中心線上移動，也就是說在汽缸夾角為零的情況下，活塞等於是在 Y 軸上移動。在這裡我們並不關心汽缸的其他幾何參數，畢竟汽缸本身並不是移動件，而我們只關心活塞在汽缸內的移動行程。活塞在汽缸內的下死點位置與曲軸中心的距離為 Cylinder-Base；活塞上死點與下死點之間的距離為 Cylinder-Len，即活塞行程長度。
由於在多汽缸聯合的情況下，多個汽缸是共用一根曲軸，而各組汽缸之間各有各自的行程錯落關係，因此需要把曲軸的轉角和曲柄的轉角進行區分。這裡假設在共同曲軸的轉角為零的狀態下，曲柄方向與汽缸方向之間存在一個 Arm-Rad0 的角度偏轉；也就是說若 Arm-Rad0 為零，則活塞初始位置即為上死點，而這是在單汽缸分析時的預設狀況。這裡注意 Arm-Rad0 記錄的是曲柄與汽缸間的初始夾角，而非與 Y 軸的夾角！
一般曲軸上的曲柄可能會被刻意製作調整，使得曲柄質心偏離曲軸中心，而 Arm-Eccen 即是用來設定曲柄的偏心距離，其正值表示偏心方向與曲軸方向相反。
這裡模擬計算的零件其實就是活塞、連桿、和曲柄這三樣，因此 Piston-Mass、Rod-Mass、和 Arm-Mass 就是對應個別的質量。
此外還有 Arm-Len 表示曲柄長度、Rod-Len 表示活塞連桿長度、和 Rod-Moi 表示連桿的轉動慣量，只不過這些參數不能手動進行設定，而是由程式透過其它參數自行計算。

關於曲柄配重

Figure 3. 曲柄配重^[2]

一般曲軸上的曲柄都會在對向做配重(如圖 Figure 3)。這個配重的基本目的是為了平衡曲柄凸出去的質量，使得整個曲柄的質心仍在曲軸質心上，免除曲柄造成的振動問題。但是有的時候我們如果野心再大以點，除了把曲柄本身配重平衡之外還想要連帶對活塞和連桿的移動進行平衡的話，便會給曲柄更多配重，使得曲柄的質心往曲柄的反方向偏離曲軸中心。

多汽缸參數定義

Figure 4. 多汽缸相關的和尺寸參數定義

搞定了個別單一汽缸的參數，現在來看看多汽缸聯合相關的參數(配置示意如 Figure 4)：

Z-Offset 表示這組汽缸在曲軸上的位置(曲軸平行於 Z 軸)
Cylinder-Rad 表示汽缸與 Y 軸之間的偏轉角
在共同曲軸轉角為零的初始情況下，各組曲柄和汽缸之間存在一個 Arm-Rad0 夾角。
最後一個 Label 就是使用者隨意定義的文字，用途是在多汽缸時畫出來的圖表上，可以讓你區分出哪一條線屬於哪一個汽缸產生的影響？

再看一些雜項的設定配置：

DATA_NUM 為繪製圖表時所需要計算的點位數量，點數愈多則理論上畫出來的結果分佈線愈細緻，不過若沒有特別想法的話建議保留預設值即可。
LAYOUT_ARM_DEG 參數與計算完全無關，只對佈局檢視有作用。這是因為這隻程式會產生一張引擎佈局圖，而在有些汽缸組態的情況下，初始狀態可能是汽缸、活塞、連桿全部連成一條線，不利於檢閱。因此設置了這個參數，用來在檢視佈局的時候給曲軸一個指定的旋轉角度。
SHAFT_RPM 為曲軸轉速，單位為 RPM。其實這個轉速隨便給就好，因為轉速的大小影響的是力量幅度，而非分佈特性。除非想要做動態分析(不過本程式並沒有實現這一部份)，否則只要隨意給一個轉速值，讓跑出來的結果數值不會太大也不會太小，正好適於觀察即可。

程式使用方式

這隻程式寫的很單純直接，將程式^[1]下載下來後，直接將檔案以文字檔打開，就會看到參數設定都在檔案開頭。將程式檔案開頭的參數修改好之後，直接執行這隻程式，正常的話稍過幾秒就會跑出結果了。沒有讀取設定檔，也沒有額外的設定方式，就是直接修改檔頭設定的數組即可。這邊我用一個設定範例作為說明，這個範例的設定內容如下：

Tip	這個小程式是以 Python 語言寫成的，所以相要拿來把玩的讀者需要先自行安裝 Python 執行環境，至於 Python 如何安裝配置的部份就不在本文裡做敘述了，讀者需要自行搜索相關教程。

DATA_NUM = 360
LAYOUT_ARM_DEG = 40
SHAFT_RPM = 400

CYLINDER_LIST = [
    [ "Piston",     1000, 0, 0, 1, 50, 56, 0, 0, 0, -40 ],
    [ "Rod",        0, 1000, 0, 1, 50, 56, 0, 0, 0, -40 ],
    [ "Eccentric",  0, 0, 1000, 1, 50, 56, 0, 0, 0, -40 ],
]

其它的設定多半是具名的，只有汽缸的條件採用陣列的型式進行設定，這樣才能更好的對汽缸的數量進行擴展。汽缸組設定項目為 CYLINDER_LIST，其內每一個元素代表一個汽缸組態；而每一個汽缸組態的內容同樣也是陣列，其內每一個項目的值與意義在程式碼內的註解已有描述，這裡就不再贅述。

這個範例我一共設定了三個汽缸，但其實觀看數值就會發現這三個汽缸是重疊在一起的，其實這是個單缸引擎。這三組設定在實際意義上其實是同一個汽缸組件的不同零件，而分開來設定的用意就是為了能更好的在結果圖表中觀察個別組件對整體的影響。在曲柄設定的部份，若曲柄是完全平衡的而沒有偏心的話，它對整體結果的影響就是零。於是為了更好的觀察曲柄偏心對整體的作用效果，範例裡給了一個很小的偏心值。

結果分析

Figure 5. 引擎各方向位移和轉動方向示意

執行完程式之後便會產生出 6 張圖表。其中的 5 張 Profile 就是引擎在曲軸轉動一圈的時間內，五個不同方向的受力變化分佈圖；其衡軸就是曲軸在一圈之內的旋轉角度，單位是徑度，而縱軸則是力或者力矩的大小。兩張 Force Profile 分別表達引擎整體在 X 軸向和 Y 軸向的受力變化；至於 Z 方向，我們所採用的分析設定結構並不可能會產生 Z 方向的力，因此就沒畫 Z 方向受力圖了。三張 Torque Profile 則是引擎整體分別在 X、Y、Z 三個軸向上的轉動力矩變化，不過因為本範例為單缸引擎置中，所以在 X 和 Y 方向上的力矩皆為零。

最後一張 Engine Layout 則與結果無關。其作用為將所配置的組態用圖形的方式繪製出來，目的為讓使用者檢閱，以確認在你所想像的引擎長相、和程式所理解的引擎長相之間是否存在落差或誤解？

曲柄

Figure 6. 曲柄的運動與作用力

在曲柄有偏心配重的情況下，曲柄會在轉動中產生一股離心力，並且由於假定了曲軸為勻速轉動，因此曲柄也只會產生這一股離心力，其分佈方向就是以曲軸為中心向外輻射。如果引擎的整體質心正好在曲軸上(如軸向對稱的汽缸佈局如水平對臥、星型等)，那麼偏心的曲柄力便總是通過質心，只會產生 X 和 Y 方向的施力，而不會在 Z 軸上產生轉動力矩。但是當引擎質心不在曲軸上時，例如本範例，就能在 Z 軸力矩分佈圖上看到偏心曲柄對著發動機軸產生的力矩變化。

一般來說曲柄都會有配重，如同前面所述，它的基本用處在於平衡掉曲柄凸出去的那一部份質量，使曲柄整體質量中心仍在轉軸上，不會因為旋轉而產生振動。但有的時候我們會想給曲柄設計更多的配重，使曲柄質心朝著反方向偏離軸心，目的是為了利用曲柄的偏心去平衡掉活塞連桿所產生的力，並且從結果圖的分析也給我們預示了這個想法的可行性。

當然有的時候也可以反過來操作，當我們已經知道一根曲軸上的曲柄剛好可以互相抵消平衡彼此的偏心效應時，也可以選擇不要設計配重，以節省重量。如果要模擬這種情況，可以將前面的 Arm-Eccen 參數設定為一個負值即可！

活塞

Figure 7. 活塞的運動與作用力

因為活塞只沿汽缸方向運動(在本例中即為只在 Y 軸上運動)，因此能看到它對 X 方向的振動影響為零，因為汽缸的施力總是通過軸心，所以也不會對轉動方向產生影響，唯一只產生了與汽缸方向相同的力。雖然說活塞只產生了一個方向的力，但是觀看數值範圍卻能發現，其實它(及連桿)才是才是導致引擎振動的最大宗來源！這就是為什麼很多其他的引擎振動分析文章只分析活塞好像就滿足了的原因，只不過我的胃口更大，所以我還想分析曲軸和連桿的影響作用！

在給定了曲柄長度和連桿長度之下，在特定曲柄角度位置下的活塞位置可由下列計算式算得：

\[ P = R \left( cos(Rad) + \sqrt{ cos^2(Rad) + (\frac{L}{R})^2 - 1 } \right) \]

其中：
Rad 為曲柄轉動的角度位置；
R 為曲柄長度；
L 為活塞連桿長度；
P 為活塞與曲軸中心的距離。

對活塞的位置做二次微分可得活塞加速度，乘上活塞質量即是活塞受力；不過這是活塞的受力，而引擎本體受到的反作用力方向相反，所以要對受力方向進行反向。

最後再來看看活塞運動施力的特性。注意到力分佈圖，活塞的力分佈並不是上下對稱的，即便活塞的運動看上去很像是跟著圓周的簡諧運動！造成這樣不對稱的原因主要是活塞並不是完全跟同曲柄運動，而是透過連桿的帶動，是圓周簡諧運動疊加一個三角形變形影響之後的結果，使得在上死點附近移動速度較快、而在下死點附近移動較慢，甚至若看加速度的話，還能在下死點附近看到反凹的現象。這個不對稱的力分佈造成的影響，會在我們之後加入多汽缸的時候顯現出來。主要的效果是即便有兩個活塞一上一下在運動，感覺上它們好像可以互相抵消，然而實際上卻不能；振動幅度雖然是降下來了，但是綜合之後還是會有一些無法消除的力被餘下並產生振動。

連桿

Figure 8. 活塞連桿的運動與作用力

相比於曲柄和活塞，連桿的運動是裡面最複雜的了，它不只上下移動，還同時左右移動、還伴同本身的旋轉，也因此活塞連桿成為我們唯一需要考慮轉動慣量的零件！不過對於解算的本身倒不是太困難，因為我們已經能夠算得活塞位置和曲柄位置，而它們二者的連線便就是活塞連桿了！

在受力分佈圖上，活塞連桿對平面的兩個方向都會產生力。觀察 Y 方向的力分佈，還能發現連桿產生的力幾乎與活塞產生的力趨勢重疊，因此若將活塞與連桿直接視為一整個整體來做分析也是非常貼近現實了。所以對於網路上的其他人只分析活塞的運動的情況，我一開始也是懷著點質疑的，但實際做了更加複雜些的分析之後也發現這麼做也不是不可，且其與實際結果其實也是大差不差的。

在 X 方向的力分佈圖上，活塞連桿與預期相同的產生了力的作用。只不過這個分佈狀態看起來非常的對稱，並且在趨勢上與曲柄偏心的趨勢是相反的，這給我們用偏心曲柄去平衡連桿運動的做法提供了可行的道路 (並且實際上也真的可以用偏心曲柄去平衡掉連桿的橫向作用力)。

最後是 Z 軸力矩分佈，也就是在曲軸方向上的轉動力矩擾動圖。活塞連桿除了因為本身的轉動而產生轉動力矩之外，其在平面的兩個方向產生的作用力因為不通過曲軸中心，因此在存在力臂的情況下便也會產生力矩，這三者疊加之後便是活塞連桿總體對引擎所產生的 Z 軸偏轉力矩。觀察分佈圖同樣會發現，連桿產生的力矩趨勢和曲柄偏心所產生的力矩趨勢大致也是程相反狀，因此其實也可以很好的透過曲柄偏心來很大程度的抵消掉；只可惜在力矩方面的分佈圖上，二者圖形趨勢並不完全一致，所以也只能一定程度的消減擾動，但並不能藉此完全消除！

條件與限制

經過這些解說和範例說明之後，相信讀者已經具備將這隻小程式自行修改參數並跑出各種花樣結果的能力了。但是這畢竟也只是一隻很精簡的小程式，它最主要的目的其實是讓我們這些門外漢可以一窺活塞引擎的振動特性；但若想要用它來分析一個具體新發動機的振動情況的話，那麼這樣的程度其實是遠遠不夠的。因為這隻程式所忽略和簡化掉的東西其實也並不少，因此使用者必須要自己知道它的能耐和限制在哪裡，好讓你在玩這隻程式的時候能夠擁有正確的認知。

首先，這程式並沒有去做過多的參數檢查和驗證等，除非會導致計算錯誤，否則它並不會過度干涉你的天馬行空。畢竟它的目的在於讓我們觀察各種可能性所產生的結果，而非幫助你實際建造一臺發動機。所以比方說你在這程式裡設定了一個曲柄比活塞連桿還長的引擎，或者四個汽缸的曲軸不在一條線上的引擎，在這程式裡面去做分析都是沒有問題的，你也可以看見假定這種東西造出來的話會呈現的受力分佈；至於這東西是否真的能夠被造出來？那就是你的問題了！

除了對於天馬行空的部份可能會導致與實際的落差之外，這隻程式還有下面這些比較正經的限制，會導致計算的結果可能與現實產生比較大的誤差：

作用力趨勢分析並不等於動態振動分析

我們從頭到尾其實只分析了零件對引擎所產生的力分佈，然而受力分佈卻並不相等於實際的振動表現，即便在大多情況下這力的分佈直接的影響了振動表現。畢竟力的作用是為振動的根源發生原因，且通常來說受力的分佈情況能直接對應振動表現，對於從結構性大方向了解一種配置情況的振動特性來說是很足夠了，但是對於實際造出來的引擎到底實際振動表現為何？卻並不是單純的受力分析可以肯定的！舉例來說，如果受力的頻率正好對上了引擎本體的自然振動頻率，就會發生共振，這樣即便所產生的源頭推動可能很小，也足以導致引擎表現出很大幅度的振動反應；於是：

本程式只計算分析了機件運動對引擎所產生的作用力分佈情況，從大的方向上去窺探了解某種引擎配置的振動特性來說應該是很足夠使用的；但若要用來作為造出一顆實際引擎的振動表現依據，則還需要再進行更多的動態響應分析才行！
假定曲軸恆速轉動

本分析程式所假定的一個重要的前提就是曲軸是「恆速轉動」的，因此並不適用於正在加速運轉或正在減速運轉中的發動機，只能用來分析穩定運轉中的引擎。

不過在實際上，即便引擎是在額定的功率下穩定運轉，曲軸的轉速其實也不是定速不變的。這原因是因為四行程的行程動作本身是不連貫的，會因為壓縮行程而減速、因為膨脹行程而加速，這點在之前的主題裡面已經討論過，即便是在飛輪的作用下也只是讓曲軸的增速與減速範圍較為收斂而已。當然，隨著汽缸的數量增多，曲軸的轉速就會愈趨向於穩定恆速，因此：

本程式在多缸引擎上的計算會與實際結果比較接近，而在汽缸數量愈少的情況下便會與實際結果誤差愈大！
假定引擎質心位置固定不變

本分析程式假定引擎的質量中心位置是固定的，然而實際上卻並不是！因為引擎內部的機件不斷在移動，所以整體的質心位置其實也是變化的。只不過在多缸引擎上，一方面是單一機件的質量與發動機整體的質量比例縮小了，二方面是機件之間存在許多影響力互相抵消的互補移動，因此會讓整體的質量中心更加趨向在固定的位置上不動。最終：

本程式在多缸引擎上的計算會與實際結果較為接近，而在汽缸數量愈少的情況下便會產生與實際結果愈大的誤差，特別是在單缸引擎的情況下！

1. 本篇文章所使用的分析程式

2. Kurbelwelle

活塞引擎 4：點火順序與振動

Sat, 31 Aug 2024 00:32:25 +0800

活塞引擎有一個逃不掉的問題就是振動，不過雖然振動躲不掉，但是我們可以盡可能的讓它小一點、平緩一點。活塞引擎的振動來源，也就是我們需要研究並對付的問題來源有二：一是由活塞、連桿、曲軸的運動所造成的引擎位移也就是振動，二是因為汽缸點火順序的不同所帶來的引擎位移。而本文要探討的便是後者，即點火順序對引擎的振動影響。

汽缸振動原理

Figure 1. 汽缸因受到空氣壓力的推擠力而被推動，上為壓縮行程時的情況，下為膨脹行程時的情況

首先，「點火造成振動」其實是一句口語表達，雖很符合直觀理解，但真正的原理稍微沒那麼單純。回顧四行程引擎原理，活塞在壓縮空氣的過程裡需要頂著壓力愈來愈高的空氣，硬把它給壓扁。當然缸內的空氣壓力不會只作用在活塞上，因為氣體的壓力是往四面八方施力的，只是往缸體側邊(也就是上圖中的汽缸上下兩邊)施的力剛好達到平衡，而往汽缸頭施加的壓力便會推動整個汽缸移動(以上圖來說就是向右移動)。跟在壓縮行程後面的動力行程，被加熱的空氣產生更強大的氣壓推動著活塞，這是發動機之所以產生動力的根源，我們以前解釋過。而同樣的氣體壓力也會施加在汽缸上，推動汽缸移動，產生的效果與壓縮行程一模一樣，只是這次的力道更大得多！

氣體壓力推動活塞的同時也會推動汽缸，而因為汽缸是被結實固定在整個引擎本體上的，因此這個氣體壓力其實是在推動著整個發動機。因為整個引擎的體量比起一個活塞而言是大得多了，因此引擎本體被推動的位移實際上是非常小的，但是作為振動的發生來源而言已是非常足夠的了！如果說這個力道是一個持續性的力量那倒還好，這樣只要結構強度足夠支撐就都沒什麼問題；然而壞就壞在這個力道並不是持續的，而是間歇性的，只在壓縮和膨脹行程出現，然後在進氣和排氣行程消失。這一下有、一下沒有的力量作用在整個引擎本體上，使整個發動機產生週期性的來回移動，這可不就是振動產生的根本原因了嗎！

點火順序與振動

了解了汽缸產生振動的原理之後，來看看多缸引擎的汽缸點火順序如何影響引擎的振動？

多缸引擎就是有多個汽缸活塞組的引擎，雖然理論上可以將這些活塞完全同步，齊上齊下，同時進氣、壓縮、膨脹、排氣，但我想一個腦子正常的設計師應該都不會這麼設計，真的把多缸活生生做成單缸模式了！通常引擎設計會將各個汽缸的行程給平均交錯開來，最好是完全平均的行程交錯，這樣能讓引擎運轉更加平順，這點在先前的主題已經解說過了 ^[1] 。

但既然各汽缸的行程錯開了，那又產生一個問題，該如何排列它們的先後順序？或者用口語方式來說，該如何決定汽缸們的點火順序？最簡單的做法就是讓它們按照排列的順序依序點火，主打一個有條有理、井然有序，然而這麼做卻會造成一個嚴重的問題：這可能已經不能用振動來形容了，而是整個引擎會晃！並且這樣會讓曲軸承受那從連桿傳遞來的力道過於集中在局部，使曲軸承受過大應力，產生的後果要不就是曲軸容易斷，要不就是為了加固曲軸結構會平白增加許多重量。

Figure 2. 完全按著排列順序點火，產生的是長週期、大幅度的晃動

Figure 3. 亂跳位置平均點火，產生的是短週期、小幅度的振動

解決這些問題的方法也很簡單：不要按照汽缸排列順序來依序點火，而是應該盡可能打亂分散汽缸點火的順序。一方面為了讓曲軸能夠分散受力，而不要集中在局部地方連續受力，所以前後一個點火的汽缸在空間上的距離是愈遠愈好；另一方面則是要避免過於簡單規律的點火順序，好破壞掉因為過於固定規律的週期而可能產生的共振現象。以上便是每款發動機設計的點火順序為什麼看上去這麼亂的原因。

那麼具體而言，發動機的設計是如何讓每個活塞以不同的相位運動的呢？以直列發動機為例，每個活塞桿都會與曲軸上獨立的曲柄連結，那麼只要將這些曲柄依據精心設計的角度錯開，就能讓各個活塞之間的行程錯開固定的行程位置 (凸輪軸的處理方式亦同)。這就是為什麼我們看到的曲軸總不是程對稱漂亮螺旋狀的彎曲，而是乍看有點的不規則彎曲的原因，也是曲軸為什麼會叫作「曲」軸的原因。

Figure 4. 彎彎曲曲的曲軸 ^[2]

直列發動機

Figure 5. 常見的直列 4 缸發動機，雖然在順序上可供變化的空間不多，但已經具有基本良好的動態平衡 ^[3]

Figure 6. 直列 6 缸是直列佈局中有名的一個型態，各方面的穩定性都相當傑出；以點火順序來看，汽缸數量是提供足夠點火亂度的保障 ^[4]

Figure 7. 直列 8 缸，暫且不論汽缸太多會導致引擎長度過長的問題，愈多的汽缸數量當然在亂度上能夠提供更加寬廣的調配設計空間 ^[5]

Figure 8. 3 缸以下已經沒有任何順序調動上的操作空間，喪失了亂度的可能，這也是 3 缸發動機之所以振動問題比較大的原因之一 ^[6]

Figure 9. 比 3 缸在行程安排上更加捉襟見肘的就是雙缸了，顧了點火平均性則機件振動表現極差，顧了機件運動則點火分佈極不平均，因此產生了多種折衷協調方案，也是雙缸發動機聲浪之所以特別獨特的關鍵原因 ^[7]

上圖是各種不同缸數的直列發動機點火順序示意，展示了那些最常見的點火順序。不過注意這些圖示也只是示意那些最常見的點火順序，並不是所有發動機都得按照這個順序點火，也不是不存在其它點火順序的實際產品，不過這些細節上的差異並不妨礙我們在大方向上對點火順序和振動關係之間的觀察理解。

透過觀察，我們可以歸納幾個簡單的結論：點火順序的亂度和汽缸數量成正比，汽缸愈多則愈能夠將順序散亂；相反的，汽缸數量愈少則愈缺乏可操作空間，3 缸以下則根本沒有亂序可言。此外，雙缸是個特別的情況，出現了多種點火間隔不平均一致的設計，反應的其實是與機件運動平衡之間的衝突折衷關係。但是有關機件運動的平衡問題不是本篇的主題內容，因此暫略過不談。簡單而言就是在雙缸情況下，若設計讓點火間隔完全平均的話，那麼剛好會讓機件運動產生的振動落在極為不利的位置，因此上面的多種設計其實就是在尋求點火間隔與機件振動之間的折衷平衡。

水平對臥發動機、及其它變體

Figure 10. 水平對臥 4 缸發動機點火順序 ^[8]

直列發動機的規則和特性也同樣可以套用到 V 型和水平對臥發動機上，畢竟這些發動機其實就是把兩排直列給左右並列在一起，兩排汽缸各自都按照直列的順序在點火，然後兩排氣剛之間再彼此交替穿插。因為 V 型點火順序就是這麼簡單，W 型也是同樣的道理， 總之絕對不是因為我找不到 V 型發動機的點火順序動畫圖， 所以這邊就不再進一步示例它們的點火順序了。

星型發動機

Figure 11. 星型 7 缸發動機點火順序

星型發動機是一個特別的例子，因為星型發動機不像直列發動機是一個活塞配一個曲柄，星型發動機的一整圈汽缸就只共用一個曲柄，一整圈的活塞都是跟著同一個曲柄一起走的，因此一個圈上面的前後活塞彼此之間具有高度協調相近的行程關係。那麼星型發動機就只能夠照著圓周順序一個一個點火一圈了嗎？這倒也不至於！剛好四行程的汽缸活塞是每轉兩圈才完成一次完整的行程週期，因此我們可以將一個圈上的汽缸分成兩組來點火，曲軸繞第一圈時只點火單數缸、第二圈只點火雙數缸，如此就能形成一個還能算得上是足夠亂且平均的點火順序。

上面說的「第一圈點火單數缸、第二圈點火雙數缸」只是一個簡單好理解的說法，實際上其實就是每次都跳過一個汽缸來點火，就像青蛙跳一樣。因此我們很容易就能發現一些事：只有當汽缸的數量是奇數的時候，才能夠用這種跳缸點火的順序在兩圈內自然的點過全部的汽缸，而沒有產生斷點或其它不連續的問題，而這就是為什麼星型發動機的單環汽缸數量總會是奇數的原因！另外當汽缸的數量(單環)愈來愈多，點火順序會變得愈來愈循序規律，愈不亂、也愈不平均。比方如果有一個單列 15 缸的星型發動機(如圖 Figure 12)，那麼即便使用上述的跳缸的方式來點火，看起和依序畫一圈其實也沒什麼兩樣。不過擺在點火順序前面會先遇到的更大問題，可能是這麼多汽缸堆起來的圈太大了，已經不實用！

Figure 12. 假想中的星型 15 缸發動機點火順序(圖片因為比例尺的關係而顯得不夠大，但實際上這幾張星型的示意圖都是同樣的汽缸大小，足見此發動機的正面面積龐大！)

Note	因為在網路上找不到合適的星型發動機解說圖，因此決定自己畫，結果就是標準的「想法很單純，實操做廢手」，這麼兩張動圖(單列和複列星型)整整花了我一個月的時間去完成！因此其它的圖就畫的比較陽春了，畢竟重在示意嘛，看得懂就好，相信讀者不會太介意的！

綜合前面分析的各種星型發動機特性，會發現若從點火順序的角度來看的話， 5 個汽缸就是最平均的最完美狀態(如圖 Figure 13)。然後隨著汽缸數量的增加，點火順序分佈表現愈來愈差的同時，引擎正面面積也在不斷加大，直到令這款發動機不再具有實用效益為止。總結而言，汽缸數量太多則振動表現不佳且引擎體積過大，汽缸數量太少則失去採用星型佈局的效益，還不如採用直列或水平對臥來得簡單經濟，又汽缸數量必須為單數，因此最終造成了星型發動機的單列汽缸數量總是只有 5 缸、7 缸、和 9 缸這三種選擇的結果。

Figure 13. 星型 5 缸發動機點火順序

不過星型發動機不是只有單列的型態，還有複列星型的型式，也就是一個發動機擺了兩圈汽缸的型態。複列星型就是兩個單列星型一前一後疊在一起，在個別單環上的特性、表現、和限制等等與單列星型完全相同，然而這兩列活塞汽缸加起來之後，卻表現出了一些更加迷人的特性。

Figure 14. 複列星型 14 缸發動機點火順序

複列星型因為多了一個曲柄，因此讓總體點火分散程度表現更加平均(如圖 Figure 14)，只多一個曲柄就解決了點火的均勻性問題(此外還同時解決了機件運動平衡性的問題)。星型發動機本來就具有一些獨特的優點，例如汽缸多而馬力大、維護簡便、耐受性高等，複列星型的型式在使馬力增一倍的同時，還平衡了單列星型在振動表現上的缺陷。因此在那個活塞引擎主宰天空的時代裡，複列星型發動機又主宰了星型發動機的份額，成為與 V 型 12 缸分庭抗禮各擁一片江山的世界。

1. 活塞引擎 2 - 多缸佈局

2. Crankshaft

3. Straight-four engine

4. Straight-six engine

5. Straight-eight engine

6. Straight-three engine

7. Straight-twin engine

8. Flat-four engine

POSIX Tree Container (tsearch) 避坑指南

Fri, 30 Aug 2024 20:25:34 +0800

最近因故發現原來 POSIX 竟然也有提供鍵值容器的函式集(tsearch)，乍看有點意思，於是就打算順手拿來用用。結果不用不知道，一用踩坑踩翻天！花費不少時間的追蹤除錯和閱讀相關說明文件(是的，我最初想說看著挺簡單就沒看了)之後，終於理清相關的用法和避坑指南。

其實 POSIX 容器的使用者應該算是小眾，也不知道留著筆記能幫到誰？也或許幫是過了 N 年之後的我自己吧！另一方面也是意識到這個容器函式庫能夠被設計的坑爹滿滿，因此探討這個程式庫的使用方法，可能在作為程式庫介面設計上的反面教材意義更大！

為什麼要使用 POSIX 容器？

首先我們得先釐清混淆，本文討論的容器，是指資料結構上的 container，就是在程式設計中用來放資料的那個容器，而不是這幾年很流行的那個作業系統虛擬化的那個 Contianer。如果你要關注的是後者的話，那麼可以直接離開了，因為本文與之完全無關！

擺在為何要使用 POSIX 容器的這個問題之前的問題，可能得先問問為何需要呼叫額外的容器程式庫？

這些資料容器就是在資料結構課程上學過的那些：陣列、串列、堆疊、貯列、和鍵值容器。這些極其基本的基礎容器，在現代的幾乎所有高階程式語言中都已經原生的提供了，所以除非有極為特別的考量，否則完全沒有需要捨簡就繁去另外使用一個容器程式庫。因此會產生使用容器程式庫需求的前提，首先就是你所使用的程式語言沒有原生提供容器相關功能，其實大概除了純 C 語言的用戶之外也沒有別人了，這就是為什麼我說這種東西是小眾用途的原因！

好的，現在我們把用戶群體限縮到了 C 語言的使用者。那麼 C 語言用戶為什麼需要一個容器程式庫呢？其實就兩個原因：簡單、方便。

作為 C 語言用戶，想必軟體工程底子是足夠堅實的。雖然資料容器的需求非常常見，但是對於簡單的資料容器，往往程式設計師能夠自己快速造一個出來。舉個最簡單的例子：陣列，訓練有素的設計師不都已經練到閉著眼睛盲打就能完成日常所需的操作了？但是對於複雜一點的容器，比方說雙向串列，難道也是每次用到的時候就重新造一個出來嗎？雖然每次手搓一個串列容器也不是辦不到的事，並且確實有不少工程師平常就是這麼做的，但是你不累嗎？如果再複雜一點，比方說鍵值容器，雖然說以大家的底子也不是造不出來，但想必這個時候已經確實萌生了「找一個現成的來用」的想法了吧！如果你還需要為不同類型的資料都造一個鍵值容器，或者如果你在許多不同的開發案中都有使用這樣容器的需求，那麼我想在你的腦海裡肯定會深深烙下一個想法：「有沒有現成的、可以容納通用格式的容器程式庫可以讓我直接調用？最好前置作業愈簡單愈好！」這，就是通用容器程式庫存在的需求和目的。

那麼除了自己造一個之外，有哪些現成可選的容器函式庫呢？我想這類的東西鐵定不少，而且各庫的特性和適用場合都不太一樣，比方有的很單純且不涉及記憶體配置、有的使用親切容易上手等等。這裡只提及我自己最喜歡也最常使用的幾個現成的程式庫： C++ STL Container、BSD Kernel Container、和本文描述的 POSIX Tree Container。首先 C++ STL Container 確實是來亂的，因為 C 語言根本無法呼叫使用這個東西！不過提出它的用意其實在於：當你有了想要找個容器程式庫的想法的時候，也許該先想的問題是能不能換個程式語言？是否現在這件事情非得用 C 語言來實現不可？

先簡單討論一下一般常用的幾種基本容器類型：陣列、串列、堆疊、貯列、鍵值容器。其中陣列太過簡單單純，用程式語言原生的功能就能直接操作，另外造一個程式庫的話能著墨的地方並不多，產生的效益也很有限，因此一般都還是自己土法煉鋼。串列開始具有一定程度的複雜性，雖然自己也能手搓串列，但能有現成工具可以使用的話也確實能省不少事。堆疊和貯列其實都可視為是加上了一些操作限制的串列，所以它的實現其實完全被串列所覆蓋了；甚至如果對於效能有所苛刻，並且不介意容納資料有限的話，也能完全使用陣列來替代堆疊和貯列的功能。因此堆疊和貯列其實就是串列或陣列的限縮特化版本，其底層實現其實是通用的，可以直接比照。最後，鍵值容器才是全部裡面最複雜也最重要的重點。鍵值容器的底層實現可能是各種二元樹、跳躍串列、雜湊容器、或其他邏輯容器，但上層總歸而言就是提供了「鍵」與「值」(或資料)的對應關係和收納容器，因此在這裡等同視之。其實在大部份的容器程式庫裡，也少有明確區別鍵與值的，而是將其二者視為一個整體進行操作，用 C++ STL 的概念來說的話，就是其實 std::map 的功能完全可以由 std::set 來實現，兩者等同視之的意思。

BSD Kernel Container 顧名思義，是 BSD 核心空間能夠取用的容器程式庫，提供了雙向串列、和紅黑樹的使用介面。雖然說這是在核心程式碼裡面的程式，但因為其本身就是個只有兩個標頭檔實現了全部功能的程式庫，加上也沒用到什麼必須得在核心空間才能取用的特殊功能，因此單獨抽取出來用在使用者空間上也是挺簡單的，這也是我平常所用的 BSD 容器的取得來源。其實 Linux Kernel 也提供了同樣功能的程式庫，也是雙向串列和紅黑樹，也是只需要兩個標頭檔。但是實際使用過後我覺得 Linux Kernel Container 的介面缺乏人性化使用體驗，加上 BSD 的許可證是比較友好有利的，因此成為我當前最愛用也是綜合評價最好用的容器工具。不過畢竟本篇的重點不在於此，所以不會更深入討論 BSD 實現的容器工具。

POSIX 也定義了使用者空間的容器相關介面，提供了二元樹容器(tsearch)、和雜湊容器(hsearch)；不過我嫌棄它的雜湊容器介面設計太垃圾，缺少使用價值，因此這裡只關注二元樹容器。 (關於 POSIX 的雜湊容器為什麼垃圾？改天有心情的話也許再寫一篇去探討吧！) 既然我前面已經給了 BSD 容器這麼高的評價，那麼 POSIX 容器顯然得有些特別的優點，否則就完全沒有介紹它的必要了。 POSIX 容器相比於其他容器程式庫(其實主要對標的是 BSD 容器)，有如下幾個優點：

已內建於支援 POSIX 規格的 C 標準程式庫，包括 Glibc。因此無需特別做什麼設定就可以直接呼叫取用，連將相關標頭檔放置到專案程式碼的合適位置這個動作都不需要；當然，除非你用的 C 程式庫不支援 POSIX，那就另當別論！ (^_^)
使用單純簡便。整個容器有關的操作函式就只有 tsearch()、tfind()、tdelete()、twalk()/twalk_r()、和 tdestroy()，相當單純，使用上也無需要另外定義資料結構、在結構內包含納入它的節點結構等等在使用之前要先完成的動作，輕量使用的話其實相當簡便。

總結 POSIX 容器就是在你有輕量使用需求，不太講究效能、記憶體等計算資源，需要托管的資料也不需要太複雜處理機制的時候，這個接近於原生的容器程式庫或許能成為你考量使用的名單之一；當然它有缺點，簡單而言就是使用邏輯與現代容器介面有差異，不注意之下容易踩坑，而這正是整篇文要論述的重點之一。

前置作業

雖然 POSIX 容器已內建在支援的 C 標準函式庫中，但是在使用前還是有少許事情需要做的：

引用標頭檔 #include <search.h>
定義 _GNU_SOURCE 巨集。

其實 twalk_r() 和 tdestroy() 不是 POSIX 定義的功能，而是 GNU 擴展；但若缺少了這兩函式的話，個人認為會讓容器的實用性大大降低，基本沒法好好正常使用。因此啟用 GNU 擴展在我認為是必須的前置作業。啟用 GNU 擴展只需要定義 _GNU_SOURCE 巨集即可，你可以直接寫在程式碼裡，在引用標頭檔前定義：
```
 #define _GNU_SOURCE
 #include <search.h>
```
當然也可以在整個專案的全局空間裡加入此項定義，以 GCC 為例，需要加入編譯選項：-D_GNU_SOURCE。

函式說明

tsearch()

void* tsearch(
    const void *key, void **rootp, int(*compar)(const void*, const void*));

集搜尋、插入、與建立一個二元樹結構於一身的函式。

使用者應管理維護一個指標變數，這個變數將指向二元樹的根節點；而函式參數 rootp 便是這個指標變數的指標。由於根節點可能在樹的操作過程中產生變更，因此這個指標的值也會處在變化狀態；然而使用者除了判斷其是否為 NULL 之外，基本無需關心該變數的值，因其具體數值是由函式庫來進行管理指派，使用者只需要確保這個指標變數本身在整個樹的生命週期為可用即可：

void *root = NULL;

這個變數的初值應設為 NULL，表示該容器為空；同樣在容器的所有元素都已被移除後，這個指標的值也會變回 NULL (用 tdestroy() 清空的例外)。由於部份函式可能會變更這個指標的數值，因此在呼叫此類函式時便會要求傳入此指標變數的指標。

key 為一個指向使用者自訂資料的指標，為本次操作所要搜尋或插入的目標。注意雖然這個變數使用了 const 修飾，但實際上函式有可能在操作完成後將此變數插入到容器內，因此在記憶體管理等事務上需要注意這件事；至於該變數是否被插入到容器內，可藉由函式返回值來進行判斷。

compar() 為使用者定義資料的比較函式，其規格與 qsort() 相同：函式傳入兩個使用者定義物件的指標，當左物件應排在右物件前面時傳回負值，當左物件應排在右物件後面時傳回正值，當兩物件相等時傳回零。

函式傳回值的型態為 void*，但其並非為使用者定義資料的指標，而是搜尋結果的資訊，這點要注意別被誤導！其傳回的值實際上是一個指向使用者定義資料的指標變數的位址，聽起來饒口，但其實就是指標的指標；也就是說假設使用者定義的資料型態為 UserData 的話，那麼傳回型態應等效為 UserData**。函式傳回值其實理解為容器疊代器(iterator)會更加合適貼切！因此後面說明都將以疊代器稱呼之。

當函式搜尋到與傳入之 key 匹配的節點時，便傳回該節點的疊代器；若容器內無匹配的節點，則函式將會新增節點，並存入 key 變數；若發生其它問題，例如無法配置記憶體，則返回 NULL。因此在函式呼叫後，建議可以比對傳回的疊代器指向之資料指標使否與 key 相同，來判斷其是否已被加入於容器內，並決定是否需要將原輸入的參數 key 銷毀等管理工作。

tfind()

void* tfind(
    const void *key, void *const *rootp, int(*compar)(const void*, const void*));

函式作用為在容器內搜尋節點。所有規格與 tsearch() 相同，除了在搜尋不到符合的節點時，本函式不會插入節點，而是傳回 NULL。

tdelete()

void* tdelete(
    const void *restrict key,
    void **restrict rootp,
    int(*compar)(const void*, const void*));

函式作用為移除容器內的一個節點。 key 為一個指向使用者定義格式資料的指標，用來作為函式比對並找出符合節點的依據； rootp 為容器根節點指標的指標； compar() 為使用者定義資料的比較函式，其規格與 tsearch() 相同。

當在容器內找到與 key 符合的節點，該節點即會被移除容器並釋放資源。返回值為被移除節點的父節點疊代器(沒錯，這個函式不會傳回被移除節點本身的資訊)、或根節點疊代器；若容器內未有與 key 符合的節點，則會返回 NULL。

此函式會自動處理並釋放被移除節點的資源，但是無法處理其內的使用者資料，再加上此函式並不能傳回被移除節點的相關資訊，因此無法像其他的容器那樣先移除節點、再銷毀使用者資料。在使用此函式移除一個節點時，正確的做法應是先搜尋容器內欲將移除的節點，然後釋放該節點內的使用者資料，然後才是呼叫此函式移除該節點。

twalk()

void twalk(
    const void *root,
    void(*action)(const void *nodep, VISIT which, int depth));

函式作用為遍歷容器內所有節點。 root 為容器根節點，action() 為當每走訪一個節點時會呼叫的通知函式。

走訪通知函式 action() 的參數 nodep 為該節點的疊代器，亦及指向該節點使用者結構的指標的指標； which 為一個列舉參數，列舉值參考下面的 VISIT 定義，其作用為指出目前走訪該節點是採用哪一種走訪方式； depth 則指出該節點之於樹結構上的深度，其中根節點為 0，並往下層遞增。

typedef enum
{
    preorder,
    postorder,
    endorder,
    leaf
} VISIT;

其中要特別注意，VISIT 所定義的走訪類型和一般在資料結構教科書上學到的類型並不相合，初使用者可能會因而被誤導！

leaf: 即指出該節點為樹的葉節點，這部份沒什麼爭議。
preorder: 同教科書上的 preorder (前序)，即先走訪中間，然後左邊，然後右邊。
postorder: 其實為教科書上的 inorder (中序)，即先走訪左邊，然後中間，然後右邊。
endorder: 其實為教科書上的 postorder (後序)，即先走訪左邊，然後右邊，然後中間。

因為 twalk() 會採用不同的方式都走訪一遍，所以實際上一個節點可能會被訪問多次，這點在使用上也需要注意！詳細來說，葉節點只會被走訪一次，但除了葉節點以外的其它節點則會被走訪三次。因此在使用此走訪函式時，應先檢查 which 參數，並略過那些你不關心的型式的重複走訪呼叫。例如若我希望使用中序走訪，則應檢查當 which 為 postorder 或 leaf 的時候才進行處理，並忽略其他類型的走訪呼叫。

最後要提醒的是在 action() 裡、以及在 twalk() 的呼叫過程中，不要去改變節點的搜索鍵屬性，亦不應對容器進行插入、刪除等操作，以避免容器內部狀態邏輯錯亂。

twalk_r()

(此功能為 GNU 擴展)

void twalk_r(
    const void *root,
    void(*action)(const void *nodep, VISIT which, void *closure),
    void *closure);

此函式功能與 twalk() 相同，函式參數和回呼函式的參數定義基本都相同，請直接參考 twalk() 相關說明；不同的部份是本函式增加了物件導向的相容性。

action() 函式取消了 depth 參數，並以 closure 參數取代之，其即為呼叫 twalk_r() 時所傳入的 closure 參數，其值和意義由使用者定義。

tdestroy()

(此功能為 GNU 擴展)

void tdestroy(void *root, void(*free_node)(void *nodep));

函式作用為一次性銷毀一個容器。

root 為容器根節點，函式即會釋放所有該根節點所指向的容器資源。至於使用者定義的資料則需透過使用者定義的 free_node() 函式進行處理，注意其中 nodep 參數即為指向使用者資料的指標，而不是疊代器(指向資料的指標的指標)！呼叫 tdestroy() 必須指派 free_node() 函式(不能為 NULL)，如果使用者的資料並不需要進行額外的處理，也應傳入一個實際上沒做任何事的函式供呼叫。

此功能為 GNU 擴展函式，若不使用或無法使用此函式，則按照 POSIX 的定義只能不斷呼叫 tdelete() 不斷刪除節點直到容器為空為止！

範例

#define _GNU_SOURCE
#include <stdio.h>
#include <search.h>

typedef int UserData;

static
int compare_user_data(const void *l, const void *r)
{
    return *(const UserData*)l - *(const UserData*)r;
}

static
const char* get_visit_label(VISIT which)
{
    switch(which)
    {
    case preorder:
        return "preorder";

    case postorder:
        return "postorder";

    case endorder:
        return "endorder";

    case leaf:
        return "leaf";

    default:
        return "unknown";
    }
}

static
void on_posix_node(const void *nodep, VISIT which, int depth)
{
    const UserData* const* iter = nodep;
    printf("Walk on node: which=%s,\tdepth=%d,\tvalue=%d\n",
        get_visit_label(which), depth, **iter);
}

static
void on_gnu_node(const void *nodep, VISIT which, void *closure)
{
    const UserData* const* iter = nodep;
    printf("Walk on node: which=%s,\tuser-arg=\"%s\",\tvalue=%d\n",
        get_visit_label(which), (char*) closure, **iter);
}

static
void on_free_node(void *nodep)
{
    const UserData *node = nodep;
    printf("Free on node: value=%d\n", *node);
}

int main(void)
{
    UserData elements[] = { 2, 8, 3, 9, 4, 6, 1, 7, 11, 5, 0, 10 };
    int element_num = sizeof(elements)/sizeof(elements[0]);
    void *root = NULL;

    printf("Build tree\n");
    for(int i = 0; i < element_num; ++i)
    {
        UserData **iter = tsearch(&elements[i], &root, compare_user_data);
        printf("Insert: new-node=%d, value=%d\n",
            *iter == &elements[i], **(UserData**)iter);
    }
    printf("\n");

    printf("Find nodes\n");
    {
        UserData key = 7;
        UserData **iter = tfind(&key, &root, compare_user_data);
        printf("Find key=%d, ret-iter=%p, value=%d\n",
            key, iter, iter ? **iter : -1);
    }
    {
        UserData key = 28;
        UserData **iter = tfind(&key, &root, compare_user_data);
        printf("Find key=%d, ret-iter=%p, value=%d\n",
            key, iter, iter ? **iter : -1);
    }
    printf("\n");

    printf("Erase nodes\n");
    {
        UserData key = 6;
        UserData **iter = tdelete(&key, &root, compare_user_data);
        printf("Erase key=%d, ret-iter=%p, ret-value=%d\n",
            key, iter, iter ? **iter : -1);
    }
    {
        UserData key = 24;
        UserData **iter = tdelete(&key, &root, compare_user_data);
        printf("Erase key=%d, ret-iter=%p, ret-value=%d\n",
            key, iter, iter ? **iter : -1);
    }
    printf("\n");

    printf("Walk through (POSIX)\n");
    twalk(root, on_posix_node);
    printf("\n");

    printf("Walk through (GNU)\n");
    twalk_r(root, on_gnu_node, "Hallo!");
    printf("\n");

    printf("Release tree\n");
    tdestroy(root, on_free_node);
    printf("\n");

    return 0;
}

執行結果：

Build tree
Insert: new-node=1, value=2
Insert: new-node=1, value=8
Insert: new-node=1, value=3
Insert: new-node=1, value=9
Insert: new-node=1, value=4
Insert: new-node=1, value=6
Insert: new-node=1, value=1
Insert: new-node=1, value=7
Insert: new-node=1, value=11
Insert: new-node=1, value=5
Insert: new-node=1, value=0
Insert: new-node=1, value=10

Find nodes
Find key=7, ret-iter=0x555c42174790, value=7
Find key=28, ret-iter=(nil), value=-1

Erase nodes
Erase key=6, ret-iter=0x555c42174750, ret-value=7
Erase key=24, ret-iter=(nil), ret-value=-1

Walk through (POSIX)
Walk on node: which=preorder,	depth=0,	value=7
Walk on node: which=preorder,	depth=1,	value=3
Walk on node: which=preorder,	depth=2,	value=1
Walk on node: which=leaf,	depth=3,	value=0
Walk on node: which=postorder,	depth=2,	value=1
Walk on node: which=leaf,	depth=3,	value=2
Walk on node: which=endorder,	depth=2,	value=1
Walk on node: which=postorder,	depth=1,	value=3
Walk on node: which=preorder,	depth=2,	value=4
Walk on node: which=postorder,	depth=2,	value=4
Walk on node: which=leaf,	depth=3,	value=5
Walk on node: which=endorder,	depth=2,	value=4
Walk on node: which=endorder,	depth=1,	value=3
Walk on node: which=postorder,	depth=0,	value=7
Walk on node: which=preorder,	depth=1,	value=10
Walk on node: which=preorder,	depth=2,	value=8
Walk on node: which=postorder,	depth=2,	value=8
Walk on node: which=leaf,	depth=3,	value=9
Walk on node: which=endorder,	depth=2,	value=8
Walk on node: which=postorder,	depth=1,	value=10
Walk on node: which=leaf,	depth=2,	value=11
Walk on node: which=endorder,	depth=1,	value=10
Walk on node: which=endorder,	depth=0,	value=7

Walk through (GNU)
Walk on node: which=preorder,	user-arg="Hallo!",	value=7
Walk on node: which=preorder,	user-arg="Hallo!",	value=3
Walk on node: which=preorder,	user-arg="Hallo!",	value=1
Walk on node: which=leaf,	user-arg="Hallo!",	value=0
Walk on node: which=postorder,	user-arg="Hallo!",	value=1
Walk on node: which=leaf,	user-arg="Hallo!",	value=2
Walk on node: which=endorder,	user-arg="Hallo!",	value=1
Walk on node: which=postorder,	user-arg="Hallo!",	value=3
Walk on node: which=preorder,	user-arg="Hallo!",	value=4
Walk on node: which=postorder,	user-arg="Hallo!",	value=4
Walk on node: which=leaf,	user-arg="Hallo!",	value=5
Walk on node: which=endorder,	user-arg="Hallo!",	value=4
Walk on node: which=endorder,	user-arg="Hallo!",	value=3
Walk on node: which=postorder,	user-arg="Hallo!",	value=7
Walk on node: which=preorder,	user-arg="Hallo!",	value=10
Walk on node: which=preorder,	user-arg="Hallo!",	value=8
Walk on node: which=postorder,	user-arg="Hallo!",	value=8
Walk on node: which=leaf,	user-arg="Hallo!",	value=9
Walk on node: which=endorder,	user-arg="Hallo!",	value=8
Walk on node: which=postorder,	user-arg="Hallo!",	value=10
Walk on node: which=leaf,	user-arg="Hallo!",	value=11
Walk on node: which=endorder,	user-arg="Hallo!",	value=10
Walk on node: which=endorder,	user-arg="Hallo!",	value=7

Release tree
Free on node: value=0
Free on node: value=2
Free on node: value=1
Free on node: value=5
Free on node: value=4
Free on node: value=3
Free on node: value=9
Free on node: value=8
Free on node: value=11
Free on node: value=10
Free on node: value=7

檢討與改善方案

依據我的使用經驗，POSIX 容器最大的問題在於介面設計上不符合人性直覺，且處處存在誤導效果。首先就是那一堆的 void* 讓我以為是我的自訂資料的指標，在引發了大量的 segmentation fault 和花費大量時間的追蹤除錯後，我才發現了問題之所在。

然後它的訪問方式也是一大嘈點，不是提供疊代器讓使用者可以用個 for 迴圈逐步訪問，能夠自由操作其它資源，並能自己決定什麼時候終止。它需要透過一個全部走訪呼叫一次走訪所有的節點，非葉節點還重複走訪了多次，而這個坑也讓我給踩了！因為要一次走訪全部節點，不只使用者不能控制走訪流程，還必須透過回呼函式進行相關處理；回呼函式也不是完全不行，在 GNU 擴展的加持下，我仍能夠完成各種需要的操作而不發生衝突，但是不方便！為了在回呼函式裡面可以取用其它相關資源，我需要定義、建立、並傳遞一個結構，雖然說這是在 C 語言底下常見的物件導向操作方式，但如果是採用了疊代器訪問的方案，完全可以避免掉冗餘的複雜度，也不用在 C 程式碼的函式外全域空間去定義可能就使用了一次的結構。

此外它關於走訪方式的定義與一般的理解認知不同這點絕對是個坑！我不清楚 twalk() 對於走訪定義和資料教科書不同是存在什麼歷史遺留因素，但是它產生的影響副作用絕對足夠忽悠第一次嘗試它的現代人。在 twalk() 的回呼函式中還存在無用的參數。雖然重複走訪同一個節點的設計很讓人出乎意料，但在此行為前提之下，which 至少還提供了使用者是否要忽略本次回呼的依據；那麼另一個參數 depth 就真的不知道意義何在了！站在一個容器使用者的角度，其實通常壓根不在意我的資料現在到底放在第幾層節點？這讓容器內部的實現自己去處理就好了！甚至我也不在乎你到底是用紅黑樹、AVL 樹、還是什麼樹來實做的？程式庫需要提供的就只是為使用者建立鍵與值的對應關係，提供以鍵查詢、以及循序訪問的方式即可！還好在 GNU 的擴展中把這個無用的參數給取消了，替換成了更加有用的 closure 參數。

綜合我在使用這些函式時所踩的坑，的確你可以歸咎於我在使用它之前沒有先仔細閱讀它的說明文件，並且事實上這些詳細的內容、定義、和規範都已經登載在它的說明文件裡；所以這裡總結出來的第一個檢討就是：在使用一個功能前，要先閱讀過它的相關說明文件！ 但是遇到的這些問題確實也指出了它的設計不符合操作直覺，是為介面設計不良的示範教案！

那麼如果讓我來定義操作介面的話，我會如何定義呢？下面就來給出相同的函式集在我修改之後的介面長相。這裡我只簡單的修改了函式介面的宣告方式，不涉及函式行為的變更、或整體程式庫結構的更動；因為如果能夠更動的話，我會想要直接設計全新的程式庫介面。同時也是順道展現一下文字的威力，看看同樣的東西改個介面表現型式就能夠產生多大的改善效果！ (相反的，光是亂命名也可以產生很強的破壞力，願所有程式設計行業的設計師都能謹記妥善命名)

typedef void* troot_t;

/*
 * 如果考量到相容性的話，其實 VISIT 不能更動！
 * 雖然原先的定義不符合當下的直覺，但若擅自「修正」定義的話，
 * 反會造成許多已存在的程式碼出現異常行為的相容性問題；
 * 但如果我們假設這個問題不存在的話，那麼就能更改成下列的名稱和順序。
 */
typedef enum
{
    preorder,
    indorder,
    postorder,
    leaf
} VISIT;

void** tsearch(
    void *key,
    troot_t *root,
    int(*compar)(const void*, const void*));

void** tfind(
    const void *key,
    troot_t const* root,
    int(*compar)(const void*, const void*));

void** tdelete(
    const void *restrict key,
    troot_t *root,
    int(*compar)(const void*, const void*));

void twalk(
    const troot_t root,
    void(*action)(const void **node, VISIT which, int depth));

void twalk_r(
    const troot_t root,
    void(*action)(const void **node, VISIT which, void *closure),
    void *closure);

void tdestroy(troot_t root, void(*free_node)(void *node));

參考資料

https://man7.org/linux/man-pages/man3/twalk_r.3.html

活塞引擎 3：散熱與排氣

Sat, 03 Aug 2024 19:26:25 +0800

作為一個燃燒汽油產生動力的機器，燃燒過的廢氣該何去何從？為什麼汽油在裡面一直燃燒，卻不會把引擎給燒壞呢？這就要說到發動機系統裡面一個至關重要的組成了：散熱與排氣。

Figure 1. 四行程引擎運作循環 ^[1]

我們再回顧 Otto 引擎的原理，汽油在汽缸裡面燃燒時會加熱空氣，那麼重點就來了：加熱！受熱膨脹的空氣推動活塞而產生了我們所需要的動力，但是留下來的廢熱卻產生了問題。在四行程引擎的第四個行程中，燃燒後的廢氣會從排氣門被排放出去，其實絕大部份的廢熱也會在這個時候跟著廢氣一起出去。但是光靠排放廢氣帶走熱量是遠遠不夠的，因為在燃燒的過程中，活塞和汽缸壁也會同樣被加熱。雖然這些熱量對比於廢氣本身的熱量只是個零頭，佔比並不高，耐何引擎內部是個不間斷而持續重複燃燒循環的環境，熱量會不斷累積並提高活塞、汽缸、乃至整個發動機的問度，當熱量不斷累積、溫度不斷上升，沒有什麼機械能夠在這種情況下依然健壯而不毀壞。因此在設計上，我們必須要想點辦法能夠足夠即時的的將這些有害廢熱給帶走，才能夠保持發動機持續健康的工作！

兩大散熱系統

Figure 2. 一具採用氣流冷卻的星型發動機，注意它的汽缸壁比較薄，並且外部長了很多散熱鰭片以提升氣流冷卻效率 ^[2]

Figure 3. 液體冷卻方案，將冷卻液流過汽缸吸收熱量，再將吸熱後變熱的冷卻液送到獨立的散熱器去降溫 ^[3]

作為一個在大氣環境下運作的引擎，不論在飛機上還是在汽車摩托車上，最簡單的冷卻辦法就是讓外面的空氣直接吹佛引擎本體，特別是大力吹佛那些最會發熱的地方，也就是汽缸。若以散熱方式來對引擎分類，則採用這種散熱方式的引擎我們就稱為「氣冷(風冷)式」發動機；對比之下，另外一種比較複雜的散熱型態就稱為「液冷式」發動機。

液冷式發動機的引擎本體會稍厚一些，內部會分佈許多縱橫複雜的管道，這些管道重點會流過整個汽缸和汽缸頭的內壁。當冷卻液體流經這些管道時就會一路吸收引擎的熱量，在引擎裡面繞過一圈以後變成熱水流出來，然後再經過其它的外部管路被導流到(可能)距離引擎有一段距離的熱交換器，並在那裡被外界的空氣吹涼。在熱交換器(或稱「散熱器」)冷卻後的水再經另一條管路回到引擎，繼續重複吸熱並冷卻引擎的循環。當然，這些冷卻液體不會自己動起來，管路中必定要有一個水泵去推動液體的流動，而這些泵通常也是由引擎的曲軸來驅動的。

氣冷式引擎為了能夠更快速有效的將汽缸內的積熱傳遞到外界被外部氣流帶走，汽缸壁一般都較薄，並且汽缸和汽缸頭的外面會造出許多層疊薄片般的散熱片，而這往往也是分辨氣冷式發動機的最顯著特徵(參考 Figure 2)。液冷式引擎因為不需要造成像鱗片付身一樣的散熱片，所以外觀上看起來會更加平滑(參考 Figure 4)，不過液冷式的引擎本體也就是汽缸所在位置會比較厚，這樣才能讓包覆冷卻管路在裡面環繞(參考 Figure 6)。此外液冷式發動機需要配套一個以上的散熱器，而這也成為液冷發動機的一個重要特徵(參考 Figure 4)；至於液冷發動機的散熱器會放在哪裡？這個就很不固定了，因為有冷熱水水管的連結，散熱器的擺放位置很具有彈性。

Figure 4. 採用液冷發動機的摩托車，注意綠色標註的散熱器，而紫色標註的汽缸外表則相較平滑 ^[4]

Figure 5. 液冷散熱器，注意左上和右下各有一個水管出入口，中間實際上是彎彎繞繞的管路讓熱液流過，照片上看到的東西實際上是管路外面覆蓋滿的密集散熱鰭片，讓氣流吹過並將熱量帶走 ^[3]

Figure 6. 一個被拆解開來的直列 4 缸發動機汽缸座，注意汽缸其實是被中空的管道包圍的，有些是冷卻液管道，有些是機油管道，還有幾個孔其實是螺絲孔 ^[5]

液冷

液冷式發動機往往也被稱作「水冷式」。這種稱呼法並沒有什麼錯誤，只是因為這些用來傳遞熱量的液體並不一定是水，所以一般還是稱其為「液冷式」會更加貼合現實。即便大部份發動機確實是以水作為冷卻液，但也不是純水，而是會添加許多的其他添加物，例如防凍成份、防鏽成份等。

採用液冷發動機的好處是發動機和散熱這兩部份可以脫開來處理，使得各自的彈性都很大。發動機的設計和安置無需過度遷就散熱，同樣的散熱器也自成一套系統，與發動機之間的依賴性不大，各自都可以朝著各自的需求和目的進行最佳優化。這就是為什麼在二戰時期的歐洲戰場，各型飛機很大比例都偏好使用液冷發動機的原因了！

於是搭配了水冷式散熱系統的 V 型 12 缸發動機在二戰時期就這麼被各家飛機廠寵愛、瓜分了航空發動機的半壁江山，放眼二戰歐洲上空的各式名機，不管是德國的 Bf109、歐洲的颶風和噴火，美國的 P-39、P-40、P-51，還是俄國的米格戰鬥機，用的全是 V 型(或倒 V 型)發動機，甚至連在不列顛戰役中轟炸英國的主力 He111 轟炸機也採用了液冷 V 型發動機。因為 V 型佈局整體幾何空間尺寸合適，用在地上的汽車可能被嫌過長，但是用在飛機上卻沒什麼大問題。機鼻子會稍長一點那就長一點了唄，可是它長方的形狀更加適合為了減低空氣阻力而打造的、粗略呈圓柱的細長機體，對於講究高速飛行的航空飛機來說簡直就是再合適不過。

Figure 7. 英國著名的噴火式戰鬥機，搭載 V 型 12 缸 Rolls-Royce Merlin 發動機，馬力 1470 hp，極速 600 km/h ^[6]

Figure 8. 德國著名的 Bf-109 戰鬥機，搭載倒 V 型 12 缸 Daimler-Benz DB 605A 發動機，馬力 1455 hp，極速 642 km/h ^[7]

Figure 9. 與中國飛虎隊同款的 P-40 戰鬥機，搭載 V 型 12 缸 Allison V-1710 發動機，馬力 1240 hp，極速 581 km/h ^[8]

Figure 10. 美國著名的 P-51 戰鬥機，搭載與噴火式同款的 Rolls-Royce Merlin 發動機，馬力 1720 hp，極速 710 km/h ^[9]

Figure 11. 英國的重型 Lancaster 轟炸機，是二戰時期少見非採用星型發動機的大型飛機 ^[10]

除了引擎本體之外，採用液冷式的發動機通常不會遭遇到來自於散熱效率不足的問題。因為發動機與散熱器為兩個不同的獨立裝置，如果在設計階段知道散熱率不足，那麼就換上效果好一點的、或大一點的散熱器；如果一個散熱器不夠，那就裝上兩個散熱器，只要能夠源源不絕的提供足夠涼的冷卻水，引擎就不會過熱！因為散熱器是個完全獨立的裝置，只需要為了最有效的將水管內熱水的熱量傳遞出去給風吹走，而無需遷就引擎，因此散熱器往往可以被設計的非常高效。散熱器不只無需遷就發動機的型式，也無需遷就發動機的位置。只要能透過管路連結傳遞冷熱水，那麼散熱器的安裝位置便非常自由彈性，幾乎可以依據設計者的通盤考量而被安置在各處角落。可以被放置在距離發動機或近或遠，對於散熱最有利的位置上。

Figure 12. 噴火式戰鬥機的散熱器位於主翼下 ^[6]

Figure 13. 同樣是噴火式戰鬥機，有些子型號有兩個散熱器，有些只有一個 ^[6]

Figure 14. Bf-109 戰鬥機的散熱器同樣位於主翼下 ^[7]

Figure 15. P-40 戰鬥機的散熱器就在發動機下，紅色標註位置則是散熱氣流出口，而位於螺旋槳軸下方的碩大散熱進氣口成為辨認 P-40 的重要特徵 ^[8]

Figure 16. 機腹下的散熱器進氣口是 P-51 戰鬥機標誌性的特徵 ^[9]

Figure 17. P-51 戰鬥機的側面角度，這裡可以看到綠色標註位置的散熱器出氣口；P-51 的設計巧思之一就是利用散熱器的熱量來加熱空氣並向後噴出，形成補充推力 ^[9]

液冷式發動機這樣看上去非常棒，讓整個動力系統可以各自放開拳腳施展，當然也不是沒有代價的；否則若非如此，哪能還有其它散熱型式存活的空間呢？液冷式發動機最大的問題就來自於多出了這一套冷卻裝置、和連結的管路。首先它直接增加了整個動力系統的重量，然後設計的複雜度和生產成本也被提高，在維護保養上也需要為冷卻系統和管路多出一份負擔，同時更複雜的系統也增加了動力系統的故障失效概率。

一旦在天空上發生了冷卻系統故障、或冷卻液洩漏，則用不了多久就能讓發動機過熱損毀！對於一般民用航空來說，這增加了保修負擔和故障機率；但對於軍事用途來說，這讓飛機對於作戰的損傷承受風險更高了；特別是那連結發動機與散熱器的長長管路被擊中波及損壞的機率也不是太低，一旦損傷卻將導致發動機罷工報銷！對於歐陸戰場來說，墜落之後只要還能跳傘逃生多半都會生還，頂多就是被敵人抓走；但是對於在廣袤太平洋上巡邏戰鬥的飛行員來說，跳傘之後若不能即時被找到救起，那就只能餵鯊魚了！

氣冷

Figure 18. 為了散熱氣流的考慮而必須橫置的直列 6 缸發動機 ^[11]

氣冷式發動機的好處就是比較簡單單純，沒有額外的散熱器、也沒有亂七八糟的冷卻管路，直接讓外面迎風的冷空氣吹過汽缸帶走熱量。少了額外的負擔，重量變輕了、結構簡化了、成本下降了、故障率降低了、維護保養更輕鬆了，並且更能夠經得住在戰場下的破壞和生存。

當然氣冷式發動機的好與壞、優與劣，是互相參雜交織的。不像液冷式發動機因為將散熱拉出來在別的地方處理，所以發動機本體可以隨便怎麼做都好，氣冷式發動機因為需要依賴迎風氣流來散熱，所以發動機的設計和佈置就不能不考慮迎風氣流這件事。像上圖(Figure 18)的例子，既想用直列六缸引擎、同時又想要氣冷，就只好把發動機給橫著放了。這就是為了妥協迎風氣流散熱的緣故而只能夠採取這樣的佈置法，因為如果不橫著放而是直的放，那麼靠後面的汽缸就只能吃到已經吹過了前面汽缸的熱氣，愈靠後的汽缸愈容易遇到散熱不良的問題。所以為了顧及吹風散熱的問題，一排汽缸就只能夠橫著放了；如果換成液冷型式，那麼這引擎就不管是橫著放、竪著放、或斜著放都沒問題了！

所以在設計氣冷式發動機時，就必須要妥善考量發動機(其實主要是汽缸)與氣流的關係。一般來說，同一個來源的空氣最多只能吹過一、兩個汽缸；再多吹幾個汽缸也不是不行，但是積熱問題和散熱的排佈絕對夠引擎設計著傷透腦筋！這就是為什麼採用水平對臥氣冷式發動機的小飛機，汽缸數總是 4 缸，而絕少 6 缸以上的原因。那麼如果需要大馬力發動機，就得多堆汽缸數量，於是看來看去只有星型排佈能夠符合多汽缸之下還能兼顧氣吹冷卻的條件了，而這就是為什麼那些採用了氣冷散熱的發動機(低馬力的小引擎除外)總是星型佈局的原因。反過來也是一樣的，星型發動機總是採用氣冷散熱型式，兩者成為互相專屬的最佳搭配。這時也許有些聰明的讀者會提出反駁：「為什麼星型佈局只能使用氣冷散熱？難道就不能讓星型發動機用液冷散熱嗎？」關於這個問題，理論上的確可以，但是通常沒有人會這麼做。至於為什麼？因為如果都決定要用液冷方案了，汽缸排佈就無需遷就氣流；既然排佈的自由度有了，為何不採用其它更有利於減少阻力或其它優點的佈局方式呢？至此就形成了一個固定的結論：在大馬力發動機上，氣冷必須採用星型佈局，並且星型佈局也只會搭配氣冷散熱。

如同我在前篇的汽缸佈局解說 ^[12]，氣冷發動機的另一個缺點就是正面截面積比較大，令飛機機身不得不變得更粗，機頭也會呈扁平而非尖銳的流線型，這導致採用氣冷發動機的飛機在空氣動力的設計上會稍嫌吃虧。回顧二戰時期經典戰鬥機的性能數據可以看出此項優劣特性，即便同時期星型發動機的馬力普遍大於 V 型發動機(因為汽缸多)，即便星型發動機少了散熱管路的負擔和重量，但是在那些飛行速度最快的戰鬥機列表裡，仍然大部份是液冷 V 型發動機的天下！

Figure 19. 德國的 Fw-190 戰鬥機，是在一眾偏好液冷發動機的二戰歐洲戰場上為數不多採用星型氣冷發動機的戰鬥機，搭載星型複列 14 缸 BMW 801D 發動機，馬力 1677 hp，極速 652 km/h ^[13]

Figure 20. P-36 戰鬥機雖然沒有名氣，但是很有比對參考價值，因為它採用 V 型液冷發動機的改款就是 P-40 戰鬥機；P-36 搭載星型複列 14 缸 P&W R-1830 發動機，馬力 1050 hp，極速 504 km/h ^[14]

Figure 21. 在二戰太平洋戰場的大海上叱吒風雲的 F6F 地獄貓戰鬥機，身材特別短圓胖；其搭載星型複列 18 缸 P&W R-2800 發動機，馬力 2200 hp，極速 629 km/h ^[15]

Figure 22. 在二戰太平洋同樣出名的 F4U 海盜式戰鬥機，雖然它在兩翼翼根處各有一個散熱器進氣口(就是俯衝時會發出特殊哨聲的聲音來源)，但是那其實是增壓的中冷器進風口，至於發動機本身則是與地獄貓同款的星型氣冷 P&W R-2800 發動機，極速 717 km/h ^[16]

Figure 23. 日本著名的零式戰鬥機，搭載星型複列 14 缸中島榮發動機，馬力 950 hp，極速 533 km/h ^[17]

Figure 24. 日本著名的紫電改戰鬥機，搭載星型複列 18 缸中島譽二一型發動機，馬力 1990 hp極速 610 km/h ^[18]

發動機採用直接氣冷散熱還有一個缺點：散熱控制較為不易，散熱條件浮動範圍較大。比如說在飛機飛在天上的時候，低溫的迎風氣流很是充沛，但是當低速起降時、或是在地上滑行、運轉時，缺乏足夠的冷卻氣流，容易導致過熱的現象。此外發動機溫度的變化範圍也較難穩定控制，比方說液冷發動機能夠隨時增減散熱程度，控制發動機的溫度在較穩定的區間，甚至在冷機剛發動的時候可以完全停止散熱工作，使發動機溫度快速升高，然而這些卻都是氣冷發動機所難以企及的。

因此氣冷發動機需要承受更大的溫度變化範圍，在零件的膨脹裕度上都要保留比較多的空間，沒法像液冷發動機那樣「精準」。此外大馬力的氣冷發動機往往會裝設有引擎專用的風扇，好在飛機沒有空速的時候仍能提供足夠的散熱氣流。並且，配備了氣冷發動機的飛機，在發動機艙的後面多半會安裝有可以控制開闔的空氣活門，在起降的低速階段、以及停在地上運作的時候，可以讓更多的空氣通過引擎本體所在區域，也是為了幫助在低速時的散熱率。

Figure 25. Fw-190 發動機罩前方設有隨螺旋槳軸旋轉的風扇，用以增加散熱氣流的流動 ^[19]

Figure 26. 一架在地面運轉的紫電改戰鬥機，可看見發動機艙後面的排氣風門已經全開，以利散熱氣流大量通過 ^[18]

排氣

引擎燃燒過後的廢氣該怎麼處理呢？說來也好笑，就是直接排掉就可以了！飛機的排氣管沒有連接什麼三元催化器、也沒有什麼消音器，就是一根管子從汽缸頭接出來，就排出去了。頂多就是把排氣管給折彎一下讓它朝向機體後方，使排氣的反作用力可以給飛機稍微增加一點點助推力！不過也正是因為如此，我們在看那些老二戰飛機的時候，才能透過飛機外面明顯的排氣管看出發動機安裝的位置，甚至可以去數排氣管的數量來判斷發動機的汽缸數量。

說到底，飛機的排氣之所以沒有額外的更多環保處理程序，最主要的原因大約是：一、早期還沒有對於環保要求的意識；二、現代航空發動機的排氣量實在是太大了，要談過濾並不現實！另外在汽車上很看重的還有一部份是噪音，然而這點噪音對飛在天上的飛機來說其實也不是什麼大事，因為活塞引擎實在是太安靜了，只要在一定的距離之外也根本不容易聽見引擎的聲音；不過什麼？你說你在地上看飛機在飛的時候明明就有聽見吵雜的轟鳴聲嗎？喔不！你聽見的那個噪音其實主要是螺旋槳切過空氣所產生的音爆，真正的引擎聲其實並不大，往往要在飛機低空略過的時候去仔細聆聽才能夠從螺旋槳製造的噪音中分辨出來。總而言之，活塞引擎飛機其實並不太注重所謂噪音的問題，它對於飛機來說是相對安靜的，除了坐在飛機裡面的人之外！不過即便是坐在艙內能夠明顯聽見發動機運作的聲音並感受到振動，艙內噪音的大宗來源仍然是來自於螺旋槳，而非汽缸引擎本身。 (因此我們常能看到小飛機的駕駛員喜歡佩帶大大的主動降噪式耳機在頭上)

看起來有關飛機發動機的排氣話題就是這樣的簡單單純，目前能夠講述的內容實在不多，這也是為什麼我把這個主題與散熱併在一起的原因。然而這個看起來簡單的排氣其實隱藏了一個有關於活塞發動機的重要瓶頸，也是未來在討論活塞發動機的發展天花板時不能不直視的一個重要問題，那就是：傳統活塞引擎對能量的使用其實是挺低效的！

活塞把空氣壓縮了比方說 10 倍以後，我們一鬆手這壓縮的空氣也就會膨脹回來，假設沒有漏氣和摩擦問題的話，那麼空氣就會完整膨脹 10 倍回到原來的體積。然而當我們在把空氣給壓縮 10 倍以後還把它給點火加熱了，那麼這空氣能膨脹的程度肯定就不只 10 倍了；至於實際可以膨脹多少倍？這問題我們往後會再細算。即便空氣可以膨脹超過 10 倍有餘，可是很不幸的，在汽缸內它最多也只能夠膨脹 10 倍，然後就得被排出去了。你說空氣它還有壓力，還能再繼續出力，那為什麼不讓它繼續推動活塞使引擎產生更多動力呢？因為我們的活塞已經到底了啊！活塞跟著連桿和曲軸走，當曲軸曲柄轉到汽缸對面的時候，這就是最大的程度了，接下來活塞得往回走，這些氣體要再不排出去的話就會變成阻力了！

這就是為什麼我說傳統活塞發動機其實對空氣能量的利用是挺浪費的，明明是仍然富有相當能量的熱空氣，明明應該還能夠用它來做什麼，但是我們卻無法利用，只能稱它為廢氣，並且眼睜睜的看著它被排放出去！但是畢竟活塞引擎的活塞就是跟著曲軸圓周走的，氣體膨脹和壓縮行程只能對稱連動，活塞到底了就得往上，即便知道熱空氣它還有力氣，卻再也利用不了。而這也是為什麼近代會有阿金森循環引擎、和米勒循環引擎興起的原因，不過這個扯遠了，以後有機會再深入討論。對於傳統螺旋槳飛機來說，眼看著仍然富有能量的高溫高壓廢氣就這麼被排放出去，卻也是莫可耐何。頂多只能把排氣管給折彎一下朝向後面，讓排放的廢氣向後噴，產生一點點的反作用力來補貼飛機的推力。至於這個一點點的推力補貼是多少呢？大約等效於給引擎增加了 50 到 100 馬力的推力吧 (同時期的發動機功率大多在 1200 至 2000 馬力左右)，聊勝於無嘍！

Figure 27. 排氣管就是從發動機汽缸以最短距離接出來的小管子，順便彎一下往後面噴以增加些許推力 ^[9]

Figure 28. 星型發動機同樣可以將排氣管接出來往後噴 ^[17]

活塞引擎 2：多缸佈局

Sat, 20 Jul 2024 19:23:57 +0800

雖然說活塞引擎只需要一組活塞汽缸就足以運作了，可是我們日常眼界所及的各式活塞發動機卻往往都裝配了不只一組汽缸，幾乎除了輕型摩托車以外，所有車輛和飛機上的活塞引擎都無一例外使用了多汽缸的形式。使用多汽缸當然是存在一些好處的，然而這些汽缸應該怎麼排列？汽缸的排列方式不只是影響發動機的尺寸參數而已，往往還極大程度影響發動機的整體性能特性。於是本篇就要先來介紹這些由汽缸排列方式而產生的引擎分類。

為什麼需要多汽缸？

Figure 1. 只有一個汽缸的引擎，廣泛被用於摩托車上 ^[1]

上圖是一個常見的單缸引擎的樣子，外表佈滿了散熱鰭片的汽缸體很明顯容易辨認，在汽缸下面就是曲軸箱，這樣就構成了一個完整引擎的大致結構。在有了飛輪的加持之下，一組活塞汽缸組件(下面將以「汽缸」簡稱之)就足以使一顆引擎正常運轉，那為什麼需要設計多個汽缸的引擎呢？原因也很單純，就是為了增加引擎的輸出功率。

當然除了增加汽缸數量之外，把汽缸做大一點也可以放大引擎功率，只不過汽缸容量放大到超過一個範圍之後，有些不良副作用會突顯出來，例如油氣均勻混合的難度增加、燃燒控制難度增加、以及轉速降低等等；然而增加多個汽缸除了也能夠增加引擎功率的主要目的之外，還會帶來一些好的副作用，主要體現在能讓引擎產生的動力輸出更加平順、運作更平穩、振動更容易受控的方面上。在有多顆汽缸協同工作的情況下，我們可以將各汽缸的行程錯開打散，這樣曲軸在旋轉過程的各個位置可能同時都有汽缸分別正在點火、正在膨脹、正在壓縮等等。這樣相比於單缸引擎轉兩圈才來一次的動力爆發，多缸引擎的動力會更加平穩綿密，更少在單缸引擎上明顯的那種間斷式的動力突波。

既然多汽缸引擎的表現這麼好，那是不是汽缸愈多愈好呢？比如一個原本排氣量(也就所有汽缸的總容量) 2 公升的汽車引擎，一般別人大概都做成 4 汽缸型式，那我就把它拆成 100 個汽缸來運作(這樣的話每個汽缸容量只有 20 cc)，那麼這樣的引擎是不是就非常非常平順了？是不是運作起來簡直就像電動馬達一樣，完全感覺不到振動了？這樣的引擎動力平順是肯定平順的，單就這樣的結論而言並沒有錯，但是現實上並不划算！把汽缸造的小的話問題其實並不大，但是汽缸數量太多反而會讓引擎整體性能下降。因為各個運動零件之間都存在摩擦消耗，連桿、凸輪軸、汽門等等這些零件本來就會產生運轉阻力，特別是汽缸和活塞之間為了氣密的緣故，其滑動阻力佔的比重本來就高，而當這些零件的數量過多時，累積起來的引擎內耗會可觀的消耗掉本應該對外輸出的動力，最終使得引擎功率降低，效率也降低。除此之外，過多的零件還增加製造難度、增加維護保養成本、也增加了故障率。歷史上也不是沒有人嘗試過打造那種汽缸很多很多的引擎，只是後來無一例外全都敗給了飛漲的各種成本和高故障率。

因此，雖然增加汽缸數量可以帶來一些明顯的好處，但汽缸數量也並不是愈多愈好。對於正常普及的活塞引擎其汽缸數量絕大多數被控制在 20 個以內，而針對家用市場的低價小功率產品之汽缸數量更是只有個位數；對於一些超輕、超低價的產品如速克達機車、割草機等則連雙缸都少見，大多都只配備了單缸引擎，除了成本因素之外，也是因為單缸的功率就已經足以應付了。

常見的汽缸佈局

直列

Figure 2. 在一戰時期的老式飛機上使用的直列 6 缸發動機 ^[2]

直列發動機可說是在所有的多缸發動機裡面最簡單的結構，把汽缸直直排成一排共同轉動一個曲軸就完成了。直列佈局的最大優點就是結構簡單且成本低，比方汽缸座可以用一整塊材料挖幾個孔就大致完成雛型了；凸輪軸也只需要兩根，做的長一點就是了；汽缸蓋、正時鏈條等等很多主要零件也都只需要共用一副即可。因此直列的汽缸佈局大量充斥在民用車輛上，幾乎所有除了講究性能的高級車以外的一般車輛全用的都是直列佈局，萊特兄弟發明的飛機用的那個 12 馬力發動機也是直列佈局，主要原因就是經濟實惠。

當然直列佈局也有它的缺點，否則怎麼還有其它佈局方式生存的空間呢？直列佈局的主要缺點就是當汽缸數量多起來以後，引擎就會變得很長，這種細細長長的引擎形狀不利於放在幾乎任何地方。直列五缸、六缸的發動機就已經長到只有特殊考量的車輛才願意使用，而直列 12 缸的引擎大概連飛機都會嫌棄它了！

所以在航空領域，只有在大約第一次世界大戰之前的飛機會出現直列汽缸發動機，因為那個時候的航空還處在萌芽摸索階段，也還沒有用上更大馬力的發動機；但是在約一戰以後，航空對發動機馬力的需求開始快速上升，直列佈局很快就被淘汰消失在航空領域了。

V 型

Figure 3. 一個 V 型 12 汽缸的發動機 ^[3]

既然把汽缸排成一列太長，那就排成兩列吧，長度直接折一半！ V 型佈局其實就是直列發動機的變體，把汽缸排成兩個直列；又因為兩排汽缸的活塞需要接到同一根曲軸上，因此下部連桿和曲軸的那部份會聚攏起來，從軸向看過去就像是英文字母的 V，因此得名 V 型佈局。

V 型佈局的好處就是相較於直列排佈而言能使長度縮短一半，雖然會使發動機橫向寬度增加，但總體幾何形狀更加適合被安置在空間侷促的車輛或飛機上。因此 V 型 12 缸發動機大量流行在第二次世界大戰期間的各式大小飛機上，從小型戰鬥機到大型轟炸機都有愛用者 (至於這個數字為什麼是 12？為什麼不是 10 缸或 14 缸？這就和引擎的振動特性有關了，這個話題暫且不談)。

V 型佈局的缺點那就是結構複雜度提高、製造和維護成本也提高。相比於直列佈局，兩個直列湊在一起的 V 佈局自然是讓整體的設計複雜度增加了，而且許多零件必須得老實的做兩份而不能像直列佈局那樣共用，比方說汽缸體就得分成兩塊，曲軸曲柄、正時機構、進氣管和排氣管等等通通都得做兩份。因此通常來說，V 型佈局在 6 汽缸以上的發動機才能體現出它的優點，而 5 汽缸以下的引擎多半採用直列佈局，在整體綜合考量下會更加合適。這也就是為什麼在汽車領域上幾乎總是直列佈局，而 V 型佈局較為少見的原因了，單純就是因為一般民用車輛的馬力需求並不需要使用這麼多汽缸。

Figure 4. 二戰時期著名的勞斯萊斯 V 型 12 汽缸梅林發動機 ^[3]

Figure 5. 紅圈標註的位置就是這架飛機的發動機所在位置，它的左右兩側有成對的兩排排氣管，據此可判斷它使用的是 v 型佈局發動機 ^[4]

水平對臥

Figure 6. 一個水平對臥 4 缸發動機 ^[5]

水平對臥佈局也是直列佈局的變體，與 V 佈局一樣將汽缸排成兩排，只是兩排汽缸不是像 V 那樣排在靠近的左右兩邊，而是兩排汽缸分立於曲軸的對面，成對的兩排汽缸成平躺的樣子，因而得名水平對臥佈局。也有一種觀點說水平對臥其實就是 V 佈局的一個特例，當 V 佈局的雙排汽缸夾角為 180 度時即為水平對臥佈局，這種說法也是非常正確且貼切的。

水平對臥佈局的好處在於引擎振動可以減到最小，設計為對稱運動的左右兩排活塞可以非常好的抵消掉彼此對引擎施加的力。相比於直列汽缸要 6 缸才能具備比較良好的低振動特性，只有 4 個汽缸的水平對臥排佈就足以達到，甚至更好！因此水平對臥佈局的發動機常見於當代的低功率航空引擎(如圖 Figure 7)。

水平對臥的次要優點是引擎整體變得比較扁平，相較於其他比較直立高聳的汽缸佈局，水平對臥式的扁平引擎可以讓車輛的重心更低，對車輛的橫向穩定性有所幫助，因此也獲得了部份強調性能和平穩的汽車製造商採用。總而言之，水平對臥佈局的好處在於可以使用最少汽缸數量的情況下，提供絕佳的振動穩定性，因此在低排氣量、功率需求較低，且講究振動穩定的領域佔有優勢。

而水平對臥的最大缺點，就是汽缸的潤滑部份設計難度較高。因為地心引力的關係，水平橫躺的汽缸內，潤滑油會自然的流動堆積在下端，導致上端缺乏潤滑，進而使得汽缸上端容易缺油而增加運作阻力和磨耗。另外水平對臥佈局會讓發動機的寬度變得很寬，在飛機上這通常也不是什麼太大的問題，但是在汽車上就會造成引擎室內空間侷促擁擠的問題，也會增加引擎的保養和零件更換的困難度。因此在汽車領域，似乎也只有極少數車廠願意採用水平對臥的引擎佈局。

Figure 7. 全球暢銷的 Cessna 小飛機，注意紅圈標示的螺旋槳軸左右兩側的散熱進風口，說明它使用的是水平對臥佈局發動機 ^[6]

星型

Figure 8. 這是一具裝配在飛機上的 9 缸星型發動機 ^[7]

Figure 9. 這是一具複列 14 缸星型發動機，上方汽缸被剖開，讓我們可以看到內部的活塞結構 ^[7]

將多個汽缸圍著曲軸環繞一圈，這種排列方式就稱為星型佈局。星型佈局曾經在航空飛機上受到大量採用，非常流行。

相較於其它的汽缸佈局型式，星型佈局的汽缸數量變化彈性比較少，環繞一圈的汽缸數量通常就有 5、7、9 這三個數字；當然這是針對單圈而言，許多星型發動機的汽缸是排兩圈的(稱為複列星型)，那麼就是上面那三個數字乘以二。汽缸數量若太少則沒有意義做成更加複雜的星型，直接做直列式會更合適；而若汽缸數量太多，因為汽缸本身也有一定寬度，這樣圍起來的圈就太大，會形成過大的迎風面(造成阻力)，並且活塞連桿的長度將超過汽缸所實際需要的太多，綜合效益反而不佳；至於為什麼只有奇數的汽缸數？這和星型佈局的點火順序有關，往後談到引擎振動和穩定性的時候再深入討論。

星型佈局的優點是功率大，原因就是汽缸數量多，平均 14 到 18 的汽缸數量(複列)提供了強勁的動力輸出，並且幾何尺寸總體合理；想想如果這個汽缸數量換成是 V 型佈局的話，那這發動機的長度得有多長啊？！因此在航空器的應用領域上，星型發動機是在所有佈局裡面，最能夠在合理的幾何空間內提供最大功率的發動機形式；而對應現實，那些功率最強大的發動機往往也是採用星型佈局。

星型佈局的另一個優點就是比較堅固皮實、耐操扛造。原因是因為環形的汽缸排列方式比其它佈局更加適合採用空氣對流冷卻，並且對應現實，絕大多數的星型佈局也是採用空氣冷卻方式。因為少掉了冷卻液及冷卻相關管路機構，星型發動機更加能夠承受損傷，這點在軍事用途上更加具有吸引力。曾經也有過在戰鬥中被打爆了一個汽缸後仍然平安返回基地的案例存在。此外少掉了冷卻系統的負擔，星型發動機也更加經得住在相較惡劣的前線機場的維護保養條件。綜合這些因素，星型佈局大量存在於各式大小飛機上，特別是那些需要大功率的飛機、或講求更加可靠的飛機，因此在二戰期間的廣袤太平洋戰場上，美日雙方便都不約而同的愛用星型發動機。

而星型佈局的最大缺點就在於幾何尺寸有些劣勢，不過這得區分汽車和飛機兩個領域分別討論。在汽車用途上，雖然星型發動機長度很短，但是它卻又寬又高。如果說水平對臥的佈局就足以讓汽車嫌棄它因為寬度而幾乎佔完引擎室的橫向空間的話，那麼星型佈局不只長的寬，而且還高，簡單來說就是非常佔空間到難以讓人忍受的地步(例如 Figure 13)。所以星型發動機在汽車領域幾乎沒有任何應用，絕大部份在車輛上的應用都是來自於個別玩家的自行改造試驗。在航空飛機上，雖然以飛機的體型來說，相較於地上的車輛更能容受星型佈局的使用，然而也確實導致採用星型發動機的飛機縱向截面積大於採用其他形式的引擎，不利於低阻力機身設計。比對二戰時期各式飛機的照片不難發現，採用 V 型發動機的戰機機身多半纖細修長，而採用了星型發動機的機身多半較粗較寬且機頭又大又平。

總結而言，星型佈局的優勢在於需求大功率的情況，並且更加皮實耐操；而缺點是它的形狀對飛機機身的阻力設計較為不利，在汽車用途上則完全不適合。

Figure 10. 機頭扁平且粗，在螺旋槳軸旁環繞了一圈的散熱進風口，說明它採用的是星型發動機 ^[8]

Figure 11. 與上圖同型的飛機處於打開外殼的維修狀態，機頭處呈雙環排列的銀色汽缸清晰可見 ^[9]

Figure 12. 體型較大的大型轟炸機對發動機的尺寸比較不敏感，但是對馬力的需求更大，因此往往是星型發動機的愛用客戶 ^[10]

Figure 13. 使用了星型發動機的改裝汽車 ^[11]

較為罕見奇特的汽缸佈局

倒 V 型

Figure 14. 採用了倒 V 佈局發動機的戰鬥機 ^[12]

Figure 15. 作為罕見的倒 V 形式發動機，注意在兩排汽缸岔開的中間空間，安排了一具機炮，機炮的炮管位置剛好從中空的螺旋槳軸穿出 ^[12]

倒 V 佈局其實就是 V 佈局，只不過一般 V 佈局的汽缸在曲軸上面，而倒 V 佈局的汽缸反過來放到了曲軸下面。大方向來說，V 和倒 V 因為本質結構是一樣的，所以幾乎所有的特性也都是一樣的，一些差異也主要體現在細節上。

因為倒 V 的曲軸在上、汽缸在下，所以上面較窄、下面較寬，所以放在戰鬥機上面能夠給駕駛員多一些些下方視野 (可以參考 Figure 17 和 Figure 18 比較駕駛員前方的機體寬度)；因為汽缸在下側，排氣管排出的夾帶火光的廢氣比較遠離駕駛艙視野，在黃昏或夜間的飛行比較不會影響飛行員視覺；此外德國人喜歡在自己戰鬥機的螺旋槳軸上安裝機炮，而倒 V 引擎的下方正好是汽缸左右岔開的空間，可以從容的安裝機炮組件。

至此很容易就發現以上優點幾乎全都是在飛行器、且是戰鬥飛行器上面才存在的，因此除了戰鬥機之外基本看不到這種汽缸佈局的應用。不過即便是戰鬥機，也就只有在二戰時期極少數的德國戰鬥機型號採用，這當然也是因為倒 V 佈局存在許多不利因素：例如機油容易累積在下面活塞位置，而不是在曲軸箱裡；引擎輸出軸在靠下端(雖然曲軸在上端，但是經過一系列減速齒輪之後，輸出的動力軸實際上在汽缸那一端)，這讓螺旋槳軸位置靠下(可以比較 Figure 17 和 Figure 5，前者採用倒 V 型佈局，後者採用一般 V 型佈局)，那麼為了不讓螺旋槳觸地，起落架就得造得更長。

Figure 16. 一架正在維修狀態而打開了引擎蓋板的 Bf109，注意外部螺旋槳軸上的大口徑機炮口 ^[13]

Figure 17. 採用倒 V 發動機的戰鬥機，注意駕駛艙前方的機頭比起下面的對照組更加圓弧點，紅圈所示的廢氣排氣管也更加遠離駕駛艙視野 ^[13]

Figure 18. 這是一架作為對照的噴火式戰鬥機，採用常規的 V 型佈局發動機，注意到駕駛艙前方的機體較為平坦且寬，排氣口的閃燄在夜間和黃昏時更容易影響駕駛員的視覺 ^[14]

W 型

Figure 19. 有三排汽缸的 W 型發動機 ^[15]

Figure 20. 布加迪威龍使用的 W 型 16 缸發動機，排列了 4 排汽缸。乍看形似普通 V 佈局，實際上是因為四排汽缸中是兩兩較為靠近的緣故。 ^[16]

為了在合理的幾何尺寸內容納更多的汽缸，一排汽缸的直列佈局太長，於是就發明了排兩排的 V 型佈局；但若當汽缸排兩排還是太長的時候，又發明了排三排、甚至四排的佈局形式，而這就稱為 W 型佈局。與 V 佈局類似，W 佈局就是把汽缸排了三或四排，形似英文字母 W，應而得名 W 佈局。

W 佈局比 V 佈局更能夠縮短引擎長度，雖然寬度也會因此增加，但總體的俯視形狀更加接近矩型，因此對於車輛的空間安排其實更加友好。總結而言 W 佈局的優勢在於大功率發動機，在能夠塞進更多汽缸的同時還能維持更加合理的幾何外型；而缺點則是增加了引擎的複雜度，無論在設計、製造、還是維護上。因此 W 佈局的應用其實並不多，比起 W 佈局帶來的優點和附加的缺點，航空飛機更能忍受 V 佈局、或採用星型佈局；在汽車上，W 佈局只有在汽缸數量大於 12 缸後才能夠體現出效益，然而一般汽車根本也用不到這麼多汽缸；因此 W 佈局只存在於極少數對功率和空間利用都有所要求的地方，例如高級跑車、或者坦克車。

Rotary

Figure 21. 使用了旋轉發動機的老式一戰時期戰鬥機，注意汽缸是和螺旋槳固定在一起旋轉的！ ^[17]

最後來看看一個最奇葩的引擎類型，叫作 Rotary Engine。 (我實在查不到什麼可靠的中文翻譯，姑且就叫它「旋轉發動機」吧，注意不是「轉子發動機」喔！)

旋轉發動機出現在大約第一次世界大戰時期。其實它看起來就和一般的星型發動機是一樣的，只不過一般星型發動機是讓引擎軸轉起來，而旋轉發動機則是讓整個引擎轉起來；如果說一般星型發動機是讓飛機本體抓住固定這顆引擎，讓軸轉起來帶動螺旋槳的話，那麼旋轉發動機就是抓住固定動力軸，讓整個引擎轉起來，然後固定在發動機本體上的螺旋槳也就一起轉起來了！

當初這樣設計的用意是讓汽缸主動動起來，更有利於汽缸周圍的空氣對流以利散熱降溫。當然我們用現代的知識基礎來看會覺得這種設計的用處不大，而且缺點可不少！讓整個引擎一起轉起來，除了考驗引擎的結構強度之外，也造成引擎轉速受到限制；此外一個這麼大的質量在高速旋轉所造成的「陀螺效應」，令飛機的操作行為和飛機具體行為之間存在一些令人迷惑的奇妙反應，導致操縱更加困難且違反直覺，也曾經因此害死不少新手飛行員。而它當初對於增加散熱的設計期望，在飛機飛在天上不斷有氣流吹過的時候，其實效益差異並不大。因此這種只有滿滿缺點卻沒什麼有用優點的奇特的發動機類型很快就被淘汰掉了！旋轉發動機的出現，其實也是因為當時的整個航空都還處在萌芽探索的階段，因而誕生的其中一種摸索嘗試而已。

活塞引擎 1：認識活塞引擎

Fri, 05 Jul 2024 23:45:35 +0800

這個系列我要來說說航空的活塞發動機，也就是一般所理解的汽油引擎這個主題。我主要是以航空的視角來探討活塞發動機，但其實活塞引擎用哪裡都是一樣的原理，在大方向上道法相通，不過鑑於一班人可能對汽車更為熟悉，所以我不時也會穿插與汽車有關的關聯和差異補充。

Tip	這裡先提點一個小知識：在航空相關的文章裡面可能不時會見到「發動機」這個詞，但其實它就是和汽車上的「引擎」是一樣的意思，只是航空領域可能有時候更喜歡用發動機來稱呼。在我的文章裡面隨時會在這兩個詞之間反覆橫跳，沒有特別的用意，可能就只是我已經習慣在某個上下文裡面這麼稱呼它而已。所以往後不管看到發動機、還是引擎，讀者都能夠了解這是同一種東西就可以了。

四行程引擎

Figure 1. 四行程引擎運作循環 ^[1]

上面這張圖就是汽油活塞引擎的最核心結構了，一個不斷上下運動的活塞就像在踩腳踏車一樣踩動下面的曲軸旋轉，這個被活塞踩出來的旋轉軸就可以接出去，驅動任何東西，如輪胎、螺旋槳、發電機……等等。那麼活塞哪來的動力去踩下面的汽缸呢？活塞的動力就來自於空氣被加熱後膨脹的壓力。整個活塞、汽缸、和汽缸上的汽門、火星塞等小零件配合運作的過程，大約區分為以下幾個步驟：

活塞往下的時候會讓汽缸內的容量增加，產生一個汽缸內的低壓(或稱為負壓)。這時右上角叫作「進氣門」的汽門剛好被一個叫作「凸輪軸」的東西頂開，因此汽缸就會把外面進氣管內的氣體 — 也就是已經混合好了汽油和空氣的混合氣(油氣) — 給吸入汽缸內。
活塞到達最低點，開始要往上走。這時進氣門已經關閉，汽缸變成密封狀態，因此活塞往上走個過程就會將混合氣給壓縮了。
活塞到達最高點，開始要往下走。在活塞到達最高點的時候，也正好是混合氣被壓縮到最小的時候，汽缸頭頂一個叫作「火星塞」的點火裝置會在電流的控制下發出火花，引燃混合氣。混合氣在極短的時間內快速燃燒(俗稱爆炸)，燃燒的熱量加熱空氣，空氣因此升溫、升壓，極欲膨脹。因此活塞在往下走的這個過程其實是被高壓膨脹的空氣給推著往下走的，而這個活塞被推著走的過程也就是引擎動力的源頭。
活塞走到最低點，開始要往上走。這時換左上角叫「排氣門」的汽門剛好被另一個凸輪軸頂開，所以在活塞上行的時候便將燃燒完的廢氣給推出去排掉。
然後活塞走到最高點，排氣門關閉、進氣門打開、活塞往下走，又回到了第一步驟，周而復始，不斷循環。

因為整個活塞汽缸的動作過程被分割為四個階段，因此這種型式的引擎又被叫作「四行程引擎」。當然活塞引擎還有一些其它的型式，比如二行程的、比如沒有火星塞的等等，但是那些型式的引擎因為極少用在航空領域上，所以這裡就不會特別提及了。

其它重要的附屬零配件

上面那些只是四行程汽油引擎最核心的原理而已，雖然在學理討論上通常也只最關心這個核心部份的分析內容，但是對於科普解說的需求來說，這樣的解釋卻還不足以說明一顆引擎如何能夠正常運作，並且一般常見的科普解說也極少見更多的解釋說明。因此我這裡將會繼續解釋其它那些從旁輔助，使一顆引擎能夠維持正常運作並輸出動力的附屬裝置的原理解說。這些我挑出來解釋的東西可能和引擎的運作原理並沒有太多直接的關係，更多的是對於看見了這些零件卻不明白它設計作用的解釋說明；其實大多數也就是我自己小的時候因為書籍解釋的不夠全面而看不明白的東西，因為曾經經驗過，所以覺得有深入解釋的意義。若您還有發現其它的疑問是我沒想到的，也歡迎來信告知。

當然汽油引擎的整個系統還有更多能夠探討的東西，但礙於篇幅的限制，在這篇裡沒有辦法簡單講明白的東西，可能將會在本系列往後的其它文章分別探討。

飛輪

Figure 2. 活塞、連桿、曲軸、和飛輪 ^[2] ^[3]

前面我們已經知道，活塞和汽缸的動作總共分成四個行程。活塞一上一下剛好讓曲軸轉一圈，所以一個行程佔據曲軸轉半圈的路程，因此曲軸轉兩圈才能完整做完一個四行程循環。

在這四個行程之中，只有第三個行程是產生動力的行程，只有這個行程可以產生並對外輸出動力；而另外三個行程卻都要消耗動力，反而需要從其他地方施力給活塞才能完成，尤其第二個壓縮行程需要施加的能量更加可觀。那麼這些需要反向從外面施加的力又是從哪裡來的呢？這是很多引擎原理解說會乎略掉的最大的謎團，也是本節要介紹的一項在汽油引擎上最簡單卻非常關鍵的零件：飛輪！

飛輪就是一個夠重的圓盤，與曲軸剛性連接一同旋轉，就是上圖(Figure 2)接在曲軸上的那個深灰色大圓盤。因為飛輪具有足夠的質量，與沒有飛輪的情況相比，它會讓曲軸的啟動更加吃力，當然也會讓已經轉動起來的曲軸停下來更加費時；當你要它轉快一點的時候，你的手(活塞)要更大力的轉動搖把(曲柄)並且持續一會兒，它的轉速才能慢慢跟上來，當然當你減少發力的時候，它也會維持轉速一陣子才慢慢的慢下來。這種特性其實就是所謂的「慣性」，放在旋轉的東西上就叫作「轉動慣量」，而之所以描述這麼多文字細節，其實也只是希望已經遺忘國中物理的人可以回想起來！

在飛輪的轉動慣性作用下，汽缸活塞間歇性的發力又吃力、吃力再發力的過程，就不會讓引擎的輸出軸充滿了汽缸活塞最直接的頓挫、振動、與抖動，因為這些短暫的力量變化都會被飛輪的大質量給平滑掉；不過當然，平滑緩和可以，完全消除是不可能的！更重要的是，飛輪的轉動慣量提供轉動能量，給予四個活塞行程中的那三個不只不出力，而且還要吃力的行程。這樣雖然四行程裡面只有一個行程可以提供動力，但是藉由飛輪的作用能將這個行程的轉動能量儲存起來，然後供給其它三個行程使用，使引擎可以維持順暢的運轉。

這麼說來，那麼如果我給引擎設置一個很大很重的飛輪不是更好嗎？理論上是這樣沒錯，飛輪的轉動慣量愈大，則它所帶來的慣性平滑效果就會愈好；只不過別忘了，動力平滑化的效果愈明顯，同時也表示增速和減速時的遲滯效果也同樣愈明顯，而過大的動力遲滯對於需要經常高低變化動力輸出的交通工具來說，可能不一定是個好特性；另外，過大過重的飛輪也會直接導致發動機的重量增加。因此飛輪也不是愈大愈重就愈好，還是得依據實際的需求折衷計算最佳的重量和尺寸！

飛輪的最佳大小和質量也和引擎的汽缸數量有關，如果引擎設計了多個汽缸，則飛輪的重要性就會下降。因為在汽缸數量足夠多的情況下，任何一個時間總會有至少一個活塞正在出力，那麼那個出力的活塞就可以透過同一根曲軸推動其它的活塞運動，每個活塞輪流出力就可以維繫引擎的持續運作。但是即便如此，在多缸引擎上往往仍舊存在飛輪這個零件，因為正如前面所描述，飛輪的作用不是只有讓引擎能夠走過四個循環行程而已，還同時具有緩和平滑化引擎間斷性暴衝提供動力的這個天性的作用。所以飛輪總是活塞引擎省不下來的一項重要零件，只不過在汽缸愈多的引擎上，飛輪重量和尺寸的佔比會比較低；而在汽缸愈少的引擎，特別是只有單缸的引擎，飛輪的重量往往就會佔到較高的比例。

凸輪軸和汽門

Figure 3. 汽門、凸輪、和正時鏈條 ^[4] ^[3]

在圍繞著汽缸和活塞的運作中，有幾個零件是需要被非常精準控制的，就是兩個汽門和火星塞。若這些零件作動的時間誤差太大，則可能會發生許多不良影響。汽門過早打開或過晚關閉，可能會讓氣體互相干擾亂竄，讓還未燃燒的油氣洩漏到排氣系統去，或者讓已經燒完的高溫廢氣回衝到進氣歧管；或者造成汽缸在應該要密封的壓縮或膨脹行程沒有密封而洩氣，從而使動力降低、效率降低等不良引想。最嚴重的情況莫過於火星塞過早點火了，這時活塞其實還沒走到汽缸頂，所以超前點火產生的推力反而會推動活塞往反方向運轉，對引擎產生強大的頓挫和振動，這也就是一般所謂的「爆震」，極易使引擎造成內傷損壞。因此這些零件的動作時機是非常重要而且必須非常精準的，那麼該如何讓它們在最正確的時間動作呢？這就是引擎的「正時」相關機構在做的事情了。

正時系統又分成「進氣正時」、「排氣正時」、和「點火正時」，一般設計由幾根數量不等的凸輪軸在特定的角度下頂開特定的機件來完成。這個凸輪軸由引擎的曲軸帶動旋轉，由於需要精準的控制曲軸轉到某個角度的時候正好讓凸輪軸轉到某個角度，所以兩軸的動力齒輪大小都是精心設計的。由於不僅僅是需要獲取曲軸的動力來帶動凸輪軸旋轉，還得要非常精準的控制雙方每時每刻的角度位置都相匹配，更不可能容許連接的皮帶打滑錯位這種事情，因此許多引擎喜歡用本身就帶有齒輪特性的鏈條來進行動力連接，就算要使用皮帶，也會使用帶齒的皮帶。

油底殼

Figure 4. 一個單缸引擎的結構示意 ^[4] ^[3]

上圖這是一個比較完整的單缸引擎結構圖，注意到引擎的最下面是一個盆的樣子，裡面還堆積了一些黃色的油，那麼這些油是幹什麼用的呢？其實引擎底下的這個盆就是拿來裝這些油用的，所以才叫作油底殼。

其實看到在引擎底下積的這些油就是「機油」，也就是引擎潤滑油。既然引擎內部充滿了各種運動零件，尤其還有活塞汽缸這種需要緊靠摩擦的機械結構，因此潤滑就是相當重要且無法乎略的事情。由於引擎機件又快速又暴力又高溫的運動，使得像腳踏車那樣塗一次油可以潤滑好一陣子的方式失效了，而是必須隨時都要對著運動零件補充供應潤滑油。因此在引擎裡面的各處零件上其實往往都能找到許多管道和噴油口，甚至在曲軸內部、和活塞連桿內部都有管道；當然具體的部份會依據引擎的設計而有所不同。在引擎運作的時候，這些噴口就會持續對著對應的位置不斷噴出機油，潤滑對應的關節和摩擦面。然後這些油在潤滑零件的同時，也會被零件的快速運動和摩擦給推擠出來，落回到最底部的油底殼；然後又被機油泵抽出來送進機油管道，再重複一次同樣的事情。

只不過這些機油管道和噴嘴太過繁複細碎，都畫出來的話可能會讓引擎原理圖看起來過於複雜，再加上這東西其實和引擎的原理關聯性已經很遠了，不弄清楚其實也不影響對引擎原理的理解。於是絕大部份的引擎解說都會省略掉這個部份，只剩下引擎下面堆積著一盆厚厚的油，讓初接觸引擎的人可能會看不明白那到底是幹什麼用的？

說點歷史

Figure 5. Otto Engine (1880s) ^[5]

本篇所解釋的這種四行程引擎最初是由德國工程師 Nicolaus Otto ^[6] 在 1876 年所發明的，因此引擎的正式學術名稱其實叫作 Otto 引擎。只是不知為什麼後來更為人所流傳的稱號反變成了「汽油引擎」，或者「四行程汽油引擎」。這些在我們現代人的認知裡彷彿稀鬆平常的知識，在那個年代卻是無數人想破頭、工程師們搞炸了無數引擎之後才誕生出來的創新發明。

Otto 的發明中最大的巧門就在壓縮這個步驟。在他之前的其他空氣引擎沒有這個壓縮過程，燃氣送進去就直接燃燒膨脹，然後動輒數公尺大小的活塞引擎卻只能產生 2 馬力功率； Otto 則成功實現將空氣先壓縮過後再燃燒的引擎，大大提高了引擎的動力輸出 (至於具體是多少功率、多少效率等我就沒查到了)。 Otto 先生的引擎雖然成功了，不過各方面仍然很原始，且它主要的銷售目的可能是對標像蒸汽機那樣的大型引擎，而我們所熟知的近代汽油引擎的樣子其實是另一位德國工程師 Gottlieb Daimler ^[7] 在 1883 年的發明。

Figure 6. Daimler 的汽油摩托車(1885) ^[5]

Daimler 改進了 Otto 引擎，實現了小型化高轉速的四行程引擎，並且發現這種引擎使用汽油作燃料更加合適，可能也是因為這個緣故使得後來民間更普遍以汽油引擎稱呼吧！？總之在 Daimler 的改良之後，汽油引擎才算是真正開啟如汽車、舟艇等小型動力工具的應用，因此也是有些人主張近代汽油引擎應該是由 Daimler 發明；不過雖然 Daimler 先生在汽油引擎的實用化發展上做出關鍵貢獻，也是汽油引擎的初代元老級重要人物，但是畢竟學理最關鍵重要的四行程結構是 Otto 先生所原創發明，因此在學術上仍然稱此種引擎為 Otto 引擎。

為什麼突然談起這些歷史呢？甚至於既然四行程引擎的發明人是 Otto 先生，又為什麼要提 Daimler 呢？因為他們對人類的航空而言實在是太關鍵重要了！甚至單從動力的角度來看，人類的飛行是因為汽油引擎的發明才能夠實現；若沒有汽油引擎的發明實用和普及，則萊特兄弟 ^[8] 根本沒有機會成為動力飛機的發明人！當然這裡不是要否定萊特兄弟，事實上除了在動力方面之外，萊特二人還有許多非常重要的關鍵性突破；只是既然這個系列主題在談的是動力，因此這裡便以動力的視角作為觀點出發，而在此觀點之下，汽油引擎的存在才是導致萊特兄弟能夠成功飛行的最關鍵因素。

早在萊特兄弟之前，人類早已進行了許多無動力滑翔飛行，其中最著名的人物大概就是德國航空先驅 Otto Lilienthal ^[9] 。不過那些都是無動力的滑翔，至於帶動力的飛行也不是沒有人嘗試過，只是無一例外全部失敗 (否則我們今天記得的就不是萊特兄弟了)。在我小時候閱讀的童書裡面其實就看到許多帶著動力引擎的飛機圖鑑，那時的我就產生了不解的疑惑：不是說飛機的發明人是萊特兄弟嗎？可怎麼這些飛機的年代都比萊特兄弟還早呢？後來才知道那些圖鑑原來是其他前人的嘗試，且無一成功離地飛行；至於為什麼那些飛機不能夠飛起來呢？最關鍵也最大的問題來自於動力 — 他們用的是蒸汽機啊！就是你在古董火車上看到的那種蒸汽機啊！

雖然那些人們已經努力把蒸汽機做小做輕了，但是耐何它本質還是個蒸汽機，就算節省到極致的基礎重量也足以狠狠壓著他的飛機待在地上升不了天。而萊特兄弟呢？有賴於他們所處的年代正好趕上汽油引擎的發明普及 (萊特兄弟首飛在 1903 年，而 Daimler 的汽油引擎發表在 1883 年，只相差 20 年)，於是萊特二人用鋁材打造了一個直列 4 汽缸的汽油引擎，總功率 12 馬力。而就是這不起眼的、足夠輕巧又同時能提供充足動力的汽油引擎，才讓萊特兄弟能夠飛上藍天； 也正是因為四行程汽油引擎的發明實用作為鑰匙，才讓人類能夠解鎖航空的大門，邁入動力飛行的新時代篇章！

Figure 7. 世界上第一架動力飛機所使用的引擎 — 萊特兄弟自製的汽油引擎 ^[10]

1. 汽油引擎

2. 曲軸

3. 由於這些引擎的原理圖都是網路上找的，因此不同的圖片描述的並不是同一個引擎！

4. 汽缸大不同

5. Otto engine

6. Nicolaus Otto

7. Gottlieb Daimler

8. 萊特兄弟

9. Otto Lilienthal

10. Wright Vertical 4

翼型系列 5：高升力裝置

Sat, 22 Jun 2024 21:51:27 +0800

前一篇 ^[1] 介紹了幾種不同種類的翼型，其各有特色和優劣勢，各適合不同條件下的用途。但是如果我們飛機的使用條件橫跨了兩種不同翼型的適用範圍，選了這個翼型的話那個條件就不好，選了那個翼型則這個條件就不好，那又該怎麼辦呢？其中最為廣泛常見的，當屬是要讓高速機翼同時也能在低速條件下飛行，因為飛機再怎麼樣也得起飛降落嘛！此為了滿足這樣的使用需求而發明出來的補丁裝置，即是本篇的主題：高升力裝置。

能變形的機翼

我們已經知道，低速飛機適合使用高翼弧的、甚至帶內凹的那種翼型，而高速飛行適合比較平直、沒什麼弧度的翼型，但如果我的飛機又想要能飛快、也能飛慢的話，在選擇翼型上就出現兩難困境了。當然慢速飛機可以說：我就選慢速翼型，我就慢慢飛就好了，飛不快就算了！可是高速飛機就不行了啊，在怎麼樣也總得需要慢慢飛的時候吧？至少需要可以起飛降落，可是那些適合較高速的翼型通通不能飛得慢啊！為了解決這個問題，其實主要是為了解決高速機翼在低速時升力不足的問題，我們需要一個能夠變形的機翼，在高速時變成高速翼的形狀，到了低速時就變成低速翼的形狀；而這其實就是高升力裝置的基礎想法。只不過目前的技術水平還沒辦法造出可以像麻糬一樣隨意變形、而且還能維持足夠結構強度的機翼結構，於是退而求其次，我只要讓它儘量變得稍微像一點就好了，反正高速飛機也不是經常維持在低速狀態飛行，在需要它的少數時間裡可以將就用得上就好了！

於是我們就像下圖(Figure 1 圖上)所示範的那樣，在正常的機翼結構上加上兩個轉軸，用這兩個轉軸就能把機翼稍微凹一下，是不是就變成了一個沒那麼漂亮的、帶高翼弧的低速翼了呢？不過也並不是所有的飛機都會做出這兩個轉軸出來，有些飛機為了節省製造成本、或者節約結構重量，就省略了靠前的那根轉軸，而只實現了靠後的那根轉軸(Figure 1 圖下)。這樣我們的機翼就被分成了前中後 3 片(或者前後 2 片)，中間的那片就是機翼本體，而前後兩片都被統稱為「襟翼」(flaps)；如要再區分的話，前面那片就叫「前緣襟翼」(leading edge flap)、後面那片叫作「後緣襟翼」(trailing edge flap)。

Figure 1. 折彎機翼使增加彎曲弧度

有了襟翼的存在，在正常飛行的時候將襟翼放平，就成了設計的正常形狀，而在起飛降落或其他需要低速飛行的時候，就把前後襟翼彎下來，可以將就著湊合提供足夠的升力。大部份的飛機甚至不是只有襟翼全收合、和全放下這兩種狀態，而是有數檔中間位置可以使用，駕駛員就能夠依據當下的飛行狀態選擇合適的機翼彎曲度(襟翼放下程度)。

當然襟翼並不只這麼單純，實際常用的襟翼還有數種不同型態，各有優劣和適合使用的情境，在下面我將一一介紹並解釋這些不同的襟翼設計。

後緣襟翼

簡單襟翼(Plain Flap)

Figure 2. 簡單襟翼(Plain Flap)

這種襟翼的結構和作動方式就如同前面所示範的一樣，就是單純的使用一個軸折彎機翼後部。它的特點就如同它的中文名稱：簡單，用最簡單的方式將平直的機翼凹成一個具有大弧度的機翼。當然這麼簡單的襟翼自然也就存在不少缺點，其中最大的問題莫過於就是氣流在彎下去了的襟翼背面容易貼不住，也就是氣流容易在那裡發生分離，具體請參照之前那篇探討機翼氣流現象的文章 ^[2] 。不過雖然簡單機翼存在著這樣那樣的缺點，但就憑著它這個簡單，它被大量使用在許多小型飛機上。且它簡單帶來的好處還不只製造便利而已，它的結構也是簡單輕巧又堅固，所以許多看起來高端上檔次的名貴飛機也採用了這種襟翼，比方大部份的現代戰鬥機。

Figure 3. Plain flaps on Van’s RV-6 ^[3]

Figure 4. Plain flaps on F-22 ^[4]

開裂式襟翼(Split Flap)

Figure 5. 開裂式襟翼(Split Flap)

單純將機翼尾部折彎的方法雖然增加了機翼的彎曲度，提高了低速下的升力，但是更高的彎曲度也使得上表面的氣流更容易發生分離。那如果只增加下表面的彎曲度，而保留上表面原來的彎曲度呢？這便是開裂式襟翼。

開裂式襟翼的流場在之前的文章 ^[2]其實已經解釋過了。開裂式襟翼只彎曲了機翼下表面但不改變上表面，在增加升力的同時，還避免了因為上表面氣流分離而導致的失速問題，而且結構一樣簡單輕巧。但缺點也如同那篇的內容所說的一樣，在機翼後面不可避免的會產生較大的迴流區，導致大阻力；它雖然維持了升力，卻產生了強大後拉阻力的副作用。

至於這個副作用是好是壞就得看情況了，在低速增加升力的同時，如果你正好不希望飛機速度太快，如果你正好想要飛機也減點速度下來的話，那麼這個副作用就不是個壞事，而這正好符合大部份降落時的情況。因此這種結構簡便、性價比高、可以在增加升力的同時順便充當減速板使用的開裂式襟翼，便也經常出現在許多小飛機上面。

Figure 6. Split flaps on DC-3 ^[3]

Figure 7. Split flaps on Zero ^[5]

延伸式襟翼(Fowler Flap)

Figure 8. 延伸式襟翼(Fowler Flap)

延伸式襟翼不像前面所描述的那些襟翼，它們都是將機翼折彎以增加彎曲度；延伸式襟翼則是將機翼尾端伸出去、延長，除了增加機翼彎曲度之外，更大的目的其實是增加機翼的面積。

確實，增加升力並不是只能用更大的彎曲度來達成，增加機翼的面積同樣也能增加產生的升力。缺點就是機翼延伸的制動機構結構較複雜，重量也較大。只不過這種單純只延伸機翼的實際應用極其少見，而大部份會整併其他襟翼的功能，這種複合式的襟翼類型我們放到後面再討論。

開縫式襟翼(Slotted Flap)

Figure 9. 開縫式襟翼(Slotted Flap)

從前我提過 ^[2] ，機翼的上表面才會出現氣流分離的問題，而下表面就沒有這種顧慮，因為除非氣流能夠把機翼給吹斷，否則下表面無論怎麼彎曲，氣流也只能被壓著轉向。那麼這就延伸出了一個想法：我能不能用別人的下翼面來幫我壓一壓我的上翼面氣流呢？然後你再仔細看看開縫式襟翼的構造，你看這是不是就是這麼樣一個原理呢？

開縫式襟翼在往下折轉的時候，會在襟翼和主翼中間出現縫隙，使機翼下表面的高壓氣流可以從這個縫隙竄出來。並且再仔細觀察還會發現，襟翼和主翼之間的縫隙形狀還是精心設計過的，這條縫隙的原理其實就是用前面主翼的下翼面來強壓折彎氣流，讓氣流去更好的貼附在後面襟翼的上表面，從而避免了襟翼上的氣流分離。

不過這種看似完美的作法也不是沒有副作用，多開的這條縫使機翼下表面的氣流可以分流往上竄，其實就是將原本高壓的下表面空氣洩壓到比較低壓的上表面來，會造成機翼上下面的壓力差縮小，白話來說就是會損失升力；不過兩害相權取其輕，在低速高攻角的飛行狀態下，與其讓氣流分離使機翼失速，損失的這一點升力自然就不是那麼重要了！

延伸開縫式襟翼(Slotted Fowler Flap)

Figure 10. 延伸開縫式襟翼(Slotted Fowler Flap)

前面介分別紹過了延伸式襟翼和開縫式襟翼，它們雖然在原理上是不同的概念，但是在實際上卻比較少見它們單獨出現在飛機上，實務上這一對哥倆好幾乎總是會參和著一起出現在飛機上。而這種又開縫又延伸的複合襟翼我們就叫作延伸開縫式襟翼。甚至於這種襟翼還可以做成多層的，襟翼後面還有襟翼，它們兩層的叫 double slotted fowler flap、三層的叫 triple slotted fowler flap，至於再多層的就真的很罕見了！

這種類型的襟翼被大量應用在現代的民航客機上，是一般人最容易接觸到的襟翼類型，也許下次坐飛機的時候選個靠窗的位置，就能在起降時看見它的詳細動作了。這種襟翼簡直是集了眾多襟翼的優點，又增加了機翼的彎曲度、以開縫吹彿的方式解決氣流分離的問題、還增加了機翼面積，那麼這麼完美的襟翼為什麼沒有淘汰掉其它所有的襟翼、進而獨霸所有的飛機呢？這就要說到它的最大缺點了：結構複雜、制動機構體積大也重量大。你看下圖實機照片，不知您是否曾好奇過在飛機的機翼下面，圖片中被圈起來的這些奇怪形狀是什麼？它們就是襟翼的支撐和制動機構的整流外殼！

Figure 11. Double slotted fowler flaps on C-13 ^[3]

Figure 12. Double slotted fowler flaps on A310-300 ^[6]

前緣襟翼

簡單襟翼(Plain Flap)

Figure 13. 簡單襟翼(Plain Flap)

簡單式前緣襟翼除了位置不一樣之外，就和簡單後緣襟翼是一樣的，原理都是透過折彎機翼，使機翼變形產生更大的彎曲度。但是因為其它種類的翼前緣的升力裝置實在太好用了，成本和副作用也沒有增加太多，所以這種簡單型的襟翼反而不是很容易見到。

克魯格襟翼(Krueger Flap)

Figure 14. 克魯格襟翼(Krueger Flap)

克魯格襟翼的作用和簡單襟翼是一樣的，都是用來增加機翼前段的彎曲弧度，但卻比簡單襟翼更加簡便。克魯格襟翼反而和分列式襟翼有那麼點相像，不是讓整塊機翼前部給彎下來，而是只有把一段機翼蒙皮給彎折出來就形成了所需要的機翼弧度。因此這種襟翼其實經常被應用在飛機上，特別是大型飛機機翼的某些難以設置前緣翼縫的畸零地帶。

Figure 15. Krueger flaps on Boeing 747 ^[7]

Figure 16. Krueger flaps on Boeing 777 ^[8]

前緣翼縫(Wing Slat)

Figure 17. 前緣翼縫(Wing Slat)

前緣翼縫的原理和前面說過的開縫式襟翼是一模一樣的，只是從後緣搬到前緣來了。只需要把機翼前緣一小塊往前面伸出去一點就會形成一個縫隙，然後下翼面的氣流就會從這個縫隙吹到上翼面來，本質上就是把前緣分出去的那一小塊變成另一片小機翼，用它的下翼面來強壓氣流，使氣流服貼主翼的上翼面，簡單這樣做就能提高主翼的失速攻角。因為前緣翼縫效果實在好，結構也簡單，因此被大量運用在飛機的機翼上。

Figure 18. Wing slats on A310-300 ^[6]

Figure 19. Wing slats on A319 ^[6]

1. 翼型系列 4：選用翼型

2. 翼型系列 2：機翼流場現象

3. Design Process: Flap Types

4. The F-22 Raptor Facts: 30 Things to Know

5. How the US Military Ended Japanese Air Dominance by Destroying the Legend of the Zero

6. Leading-edge slat

7. Why are Krueger flaps not used on the Boeing 747s?

8. Missing Krueger flap on the 777 wing

翼型系列 4：選用翼型

Sat, 08 Jun 2024 09:47:28 +0800

在前面幾篇文章裡 ^[1] ^[2] ，我講解過機翼升力的原理，並探討了發生在機翼上的各種流場現象，了解了為什麼機翼剖面要做成那些形狀的原因。本篇就要來探討，哪些翼型適合被使用在什麼情況下的問題；或者也可以說，當一個設想的操作環境定下來之後，我們可以怎麼選用翼型的一個方向。

當然每一個種類的翼型都還細分為好多子型號，甚至你自己還可以特製一個自己專屬的。因此我這裡並不會細細比較各種翼型微小差異及影響，僅只會從大的方向上，對差異較為巨大的幾種翼型去做解說。

普通常見的翼型

Figure 1. 在教科書上最常見的翼型^[3]

這是一個我們經常能夠見到的機翼剖面形狀，它的身影出現在各種教科書、航空飛機原理解說圖鑑、大部份螺旋槳飛機、以及各種航模遙控飛機上面。它的優點就是各項性能參數中庸，沒有特別突出的部份，也沒有什麼明顯的缺點，當你遇到一個需要選用翼型的情況，卻還沒有特別想法的時候，通常選它就對了！

高弧內凹翼

Figure 2. 彎曲弧度特別大的機翼，可以有效率的將氣流折灣一個很大的角度^[3]

高翼弧的機翼一般都用在低速用途上，因此當你看到什麼飛機的機翼它比例上很厚的話，就表示它的翼弧很高很彎，基本就能知道它是適合低速飛行的；如果你看到的機翼不只厚，下翼面還內凹的話，那就知道它的飛行速度多半是慢中之慢。低速翼型的設計重點往往在於高攻角，這是因為升力與氣流的動能(也就是速度)成正比，當速度低的時候就必須要抬高攻角才能產生足夠的升力，因此才讓較高攻角範圍的性能成了重點。

給初接觸機翼的人一個小提示：要看懂高翼弧機翼的原理，請不要把它放平來看，而是應該把它擺一個比方說 10 度、20 度的攻角再來觀看。高翼弧機翼的除了尾部往下彎曲之外，重點也在於頭部往下彎曲，這是為了讓頭部在高攻角的情況下能夠更好的貼合於迎風氣流，減小氣流在頭部的動能消耗。將氣流順暢的接進來之後，再用一個圓弧路徑將氣流和緩的改變方向，因此就自然形成了這種高彎曲度的機翼剖面形狀。

這種帶有高彎曲度的翼型，可以在低速的時候配合適當的攻角大量偏折氣流而產生升力，是低速加上高升力需求時的一個極佳選項，然而這似乎是它唯一的優點了。在之前的解釋中 ^[2] 我們可以知道，這種高彎曲的翼型加上高攻角便會容易發生失速，當速度夠低的時候因為撐得住，所以無妨；但當速度往上提高之後，它的失速攻角就會比其他機翼來得低。但缺點不止於此，在速度逐漸提高起來以後，升力也會因此而提高，也就是說這時要維持飛行所需要的升力，其實只要相對較小的攻角就能夠提供了。然而比起其他翼型同樣處在低攻角的狀態，這種高弧的翼型卻讓氣流彎彎繞繞，平白增加了阻力。簡單的說就是這種高弧的翼型可以在低速條件下有效提供升力，但在脫離了低速範圍後便處於不利的情況，白話意思就是不適合高速。

除了空氣動力上的性能以外，這種漂亮的弧形同時也在告訴你它的加工製造較為繁複困難，而且相比於前面的普通翼型下翼面是個平版，這種翼型的上下翼面可都是曲面。另外，下翼面的向內凹陷也導致機翼內部空間被壓縮，當需要利用機翼內部空間的情況下，比如裝載燃油、攜帶設備或武器等，此時它內部空間較窄小小的缺點便會顯現出來。

總結就是這種翼型極其適合在低速場景下需要高效產生升力時使用，特別如果對機翼內空間需求比較低、或無需利用機翼內部空間的話，這就會是個極為適合的方案。

高弧外凸超厚翼

Figure 3. 以增加機翼厚度為主要考量點的機翼^[3]

如圖所示，這種翼型與前面介紹的高弧翼有異曲同工之妙，只不過人家是往內凹，而它是往外凸。相同的是，它們倆都更容易發生氣流分離、都適合在較低的流速下運作，不同的是前一種內凹翼型能高效產生升力，而這外凸的翼型基本產生不了太多升力。

這種翼型的主要優點是提供了大量的內部空間，可以容納更多東西填充在裡面；事實上上圖是一個螺旋槳較靠近根部的翼剖面形狀，因此利用了它結實又方正的形狀提供了整根槳翼的結構支撐。

渦輪葉片

Figure 4. 彷彿不怕氣流分離般的超誇張彎曲度機翼^[3]

這種翼型是一種彎曲弧度更為誇張的內凹翼，因此我們知道它是為了極高效產生升力(轉矩)的目的而存在；看它尖尖的前端，我們知道它是被設計在特定攻角下高效運作的存在。

事實上這是用在航空引擎渦輪葉片的翼型，相較於飛機機翼可能因為不同飛行狀態而希望機翼能夠適應較大範圍的攻角區間，渦輪葉片只需在特定攻角下工作，但是要非常高效的產生升力。因此可以讓它頭部變得比較尖銳，好最大限度的減少前端氣流的消耗，而高弧度的彎曲形狀就是為了盡可能最大限度產生升力的目的，白話說就是盡其所能將氣流的動能壓榨出來變成轉動力矩(升力)。

可是按照前面解釋的邏輯，這腫大彎曲的翼型應該適用在低速的環境下才對，為什麼渦輪能夠用上它呢？這樣不會氣流分離導致失速嗎？這就要提到它工作的環境了，在航空引擎的渦輪段工作的它，其實這個區段的空氣是剛被加熱過的高壓空氣，然後一路在膨脹，因此渦輪葉片才能夠使用這麼大的攻角來工作而依然保持氣流不分離。

壓縮機葉片

Figure 5. 只能適應特定攻角的超薄葉片^[3]

這也是在航空引擎內的葉片翼型，不過不是在渦輪段，而是在壓縮機段。它尖尖的前端告訴我們它也是被設計在特定攻角下高效運作的，事實上也真是如此。 (壓縮機葉片適用的攻角區間很窄，因而強化了這樣那樣的問題。這是一個伏筆，先挖個坑，以後有機會填上) 雖然這翼型很薄很平，但還是看得出來它是內凹的弧翼，因此它的用途也是為了高效產生升力(高效消耗軸的轉矩)，事實上也是如此。不過與渦輪葉片相反，它是工作在一個空氣不斷被壓縮的區間，因此更容易發生氣流分離，這使得它的整體翼面被坡度設計的更為平緩，能夠正常工作的攻角範圍又窄又低。

高速翼

Figure 6. Laminar Flow Airfoil ^[4]

這種翼型是為了高速飛行而設計 — 不過這裡的高速指的是次音速範圍內的高速。

在高速的情況下，其實機翼只需要較小的攻角就能夠產生所需要的升力，而中低速那些彎彎繞繞的翼型在小攻角狀態下用處不大，還會附帶產生好多阻力。因此這些高速翼型就被設計的比較平緩而沒有過於誇張的彎曲度，使它在滿足所需要的足夠升力之下儘量減少阻力的產生，最後就成了類似上圖這種長相的翼型。除了翼型曲面比較平緩之外，另一個可能更加顯著的特徵就是，這種翼型最厚的地方大約在弦長的一半位置，而非如傳統翼型的最厚處靠近前端 1/4 處。

這種翼型的優點就是在高速狀態下阻力較小，在低攻角狀態下阻力更特小，這使得選用了這種類型翼型的 P-51 野馬戰鬥機，之所以能夠擁有高飛行速度和超遠航程優勢的其中一向關鍵技術。另一方面，這種翼型的優點都體現在高速且低攻角狀態下，一旦攻角拉起來(比方戰鬥機在戰鬥中的機動動作)，則它的表現相比其他傳統翼型並沒有特別優勢；特別是在低速狀態下，它往往不能提供足夠使用的升力！不過倒不用擔心使用了這種機翼的飛機在低速下會不會墜機的問題，因為還有高升力輔助裝置的存在，不過那是另一個話題了，暫且不展開。

簡單總結：這種高速翼型的優勢在於低攻角下的高速巡航能力，至於在低攻角範圍以外的性能表現則顯得普通；罩門則在低速狀態下產出升力的效能低落，需借助其他輔助設計的幫忙。

超臨界翼

Figure 7. 能在次音速範圍內衝到極限的機翼^[5]

這種看起來奇怪的翼型，可能會讓初入門航空空氣動力學的人看得有點摸不著頭腦。其實它的設計目的與前面說的高速翼型相似，只不過前者的高速翼型只是為了在(次音速的)高速範圍區間內使用；而超臨界翼型則是為了在次音速範圍內，頂著能多快就多快的最高速限飛行！

當物體在氣流中以音速或超音速的速度行進時，就會產生超音速領域特有的「震波」現象。對於震波的原理和影響等等需要至少一個以上的主題來探討，所以這裡我們暫且先把震波的具體細節放一邊(又挖了一個坑)，只需要先理解為：一旦發生震波就會出現各種妖魔鬼怪，總之很不好就對了！有了上述的理解後，這種翼型的設計目的便浮現出來，那就是：在不許出現震波的前提下，能容許飛的愈快愈好！

機翼、或任何物體在氣流中行進時，氣流都會在物體表面的不同區域增速或減速。意思就是說，即使這個物體在跑的很快的時候，雖然本身還沒有達到超音速的速度，但是它身上某些局部氣流可能已經到達、或超過音速了。這就導致一個現象：雖然此時該物體的移動速度其實還沒達到音速，但是卻已經出現了超音速才會出現的問題，對於這種狀態有一個專有的名詞叫作「穿音速」(transonic)。如果有一個物體它的表面氣流加速減速效果比較劇烈，那麼也許它本身的行進速度只有 0.7 倍的音速(即 0.7 馬赫)，但是它身上的某個部位可能已經被加速達到了音速(即 1.0 馬赫)，就會開始出現震波。那麼如果另一個物體它的表面氣流加減速比較緩和的，那麼也許它的本體速度要達到 0.8 馬赫的時候，它的某個地方才會開始出現震波，那麼這個物體它就可以跑的比前一個物體更快一些！而這其實就是超臨界機翼的設計重點：儘量讓機翼的氣流加速程度減少，使它可以壓在不產生震波的邊緣飛行，能飛多快就飛多快。

回顧之前的解釋內容 ^[2] ，我們知道氣流在機翼上表面會被加速，而且機翼上表面彎曲的愈厲害，則氣流加速愈多。使用一般翼型的飛機也許在飛行速度達到 0.7 馬赫以上的時候就會面臨與震波有關的問題，開始出現油耗大量增加但速度基本不會增加的現象、以及飛機難以控制或無法控制等問題(後面這個問題倒不一定會出現，具體要看飛機的操控設計)；而使用了超臨界翼型的飛機則可能可以將這個速度的極限推展到 0.85 馬赫，意思就是在同樣的油耗下，能飛的比其他人更快！

為了延後機翼上表面震波的產生，就要降低氣流在上表面的加速效應，這就是為什麼超臨界機翼的上表面會如此平坦的原因，比前一個介紹的高速翼型還要再更平坦，感覺幾乎可以在上面煎蛋。但是與高速翼型一樣，翼型平坦了就會導致產生升力的效果降低，為了彌補這缺點，於是就在下表面做了文章，反正下表面原本的氣流效應就是增壓降速，因此經得起折騰。這就是為什麼機翼下表面的後段會往裡面這麼內凹一下的原因，就是為了增加將氣流轉折向下吹的效果。但是也因為大量的氣流在機翼後部位置被折轉向下，因此尾端會產生一個較大的上翹力矩，使飛機的低頭趨勢變大，不過這是飛機平衡和配平最佳化那方面需要去傷腦筋的事情了！總而言之，超臨界翼型的特徵就是上翼面極其平緩，然後頭部比較大些，機翼最厚處與高速機翼同樣在大約中間位置，並且在下翼面尾段有一個明顯的內凹形狀。

來到結論，這種翼型的優點(可能也是唯一的優點)在於可以在合理的阻力範圍內，容許飛行極速更加接近音速。它的設計理念延伸於高速翼型，但更加極端；如果只是要飛的快的話其實用不著它，但如果要飛到最快(但又不想超音速)就需要選它。而它的缺點也和高速翼型一樣，高攻角性能不突出、低速下升力不足，因此在低速時也需要其他輔助設計的助力，此外還多了低頭力矩大，使飛機的平衡負載加重的副作用。因此選用這種翼型的飛機幾乎都是高速巡航的大飛機，例如近代的幾乎所有大型客運飛機等，但出了這個應用領域就罕見選用此種翼型。

對稱翼

Figure 8. 上下完全對稱的機翼^[6]

前面我們介紹的所有翼型都有一個共同點，那就是都是為了正飛的目的設計的，因此正著飛的效果各有各的好；但是一旦上下倒過來飛，情況就讓人有點不忍直視了！如同我在之前的解釋內容 ^[2] 所說，各種形狀只要能夠導氣就能夠產生升力，差別在於產生升力的效率和成本。所以毫無疑問的，所有翼型倒著都能夠產生升力，只是看具體翼型的不同，有些的效率可能過於慘不忍睹！不過一般來說這個問題並不大，因為通常倒著飛的機會不多，就算真的倒過來飛多半也是暫時的，甚至有些飛機根本也就沒考慮過讓你翻過來飛的情況，所以一般不會特別在意這種情況。

不過如果在你的應用需求上經常會需要翻過來翻過去的飛，又不希望倒過來飛的時候效果太差的話，就得考慮使用這種對稱的翼型了！這種翼型的缺點就是在正向狀態下的效率、阻力等等性能都不如前面那些翼型傑出，但是優點是翻過來的時候性能也是一樣的，不會像前面那些翼型那樣性能直接往下掉。因此選用這種翼型的飛機多半都是特技飛行用途的飛機。

不過前面說的是只應用在飛機主翼的情況，但其實除了主機翼以外的其它翼面如方向舵、穩定翼等等。這種應用場所可能就不是分上下，而是分左右，而氣流從左邊吹來或從右邊吹來的機會都是一樣的，因此在這些地方的翼型首選就是對稱翼型了。

超音速翼型

Figure 9. 超音速適用菱形翼^[7]

相比於前面頂著震波即將出現的邊緣在玩火的超臨界機翼，超音速機翼就有點像是放棄治療了！在本體都已經超音速的情況下，震波是不可能不出現的。於是乾脆破罐子破摔，既然震波橫竪避免不了，那就玩起來吧！

在震波主導的超音速世界裡，震波是能少一點最好、稍微斜一點不那麼正的震波更好，而震波喜歡在有轉折的地方出現，那麼轉折的地方能少點就少點唄，於是才會看到超音速翼型就是這麼簡單的一個菱形。然後圓滑的頭部會導致阻力較大的正震波產生，所以頭部是愈尖愈好，於是最終就長成了上圖我們看到的這種形狀。

這種超音速翼型經常可以在各種飛彈的彈翼上面看到，此外還有部份超音速高速飛機也會採用，例如 F-104。不過在飛機上的超音速機翼看起來比較不會是那麼標準的超音速翼型，而是較為折衷變化後的翼型，因為飛機不像飛彈一股勁往前衝到底就好，飛機還得考慮在沒有超音速的時候性能也不至於太差。

Figure 10. F-104 機翼剖面^[8]

平板翼

Figure 11. 一片平板，沒有比這個更簡單的了！

最後我們來看看一個可能更常見，但一般可能更難被想到的翼型 — 平板。

平板翼在幾乎所有方面的性能數據都是敬陪末座，無論使用在何處幾乎都只有被嫌棄到死的份。但就是這麼一個人人見了都說不好的翼型，卻有一項無與倫比的優點：製造簡單！所以在那些廉價、需求大量、對性能不太需求的用途裡，反而是這種翼型被大量使用，反而成為了我們一般人在日常生活中可能最常見到的翼型。比方說，當你在折紙飛機的時候，請問你會把機翼剖面折成上述哪一種精美的形狀呢？不，你一定只會折一片平板翼就結束了！當你需要製造一大堆用來製造彈幕的廉價火箭彈時，請問火箭彈的彈翼選用哪種翼型最合適？我猜你一定會只想要拿一片鐵板焊上去就完事了！更別提那些廉價兒童玩具、風向旗標翼片、冷氣出風口葉片、和各種廉價風扇等等，平板翼型也許才是真正充斥在你我身邊的東西。

1. 翼型系列 1：機翼升力原理

2. 翼型系列 2：機翼流場現象

3. Wikipedia: Airfoil

4. Wing Design - Level 3 - Wing Boundary Layer

5. NASA SC(2)-0714 airfoil data corrected for sidewall boundary-layer effects in the Langley 0.3-meter transonic cryogenic tunnel

6. Unable to sample NACA 0012 symmetrical airfoil

7. Supersonic airfoil with oblique shock waves and expansion waves

8. 寡妇制造机玩过比眼镜蛇机动还危险的特技动作，且只成功过一次

翼型系列 3：那些升力原理哪裡錯了？

Sun, 02 Jun 2024 00:21:35 +0800

前面我寫了兩篇文章 ^[1] ^[2] 來解釋機翼產生升力的原理，介紹了空氣吹過機翼表面所產生的一系列現象，並解釋了解釋機翼被造成那些形狀的真實原因。這一篇我要來解釋一些流傳的機翼升力原理說法，並探討他們為什麼不對？

以下我會逐一介紹我聽說過的一些機翼升力原理說法，並分析它們哪裡不對、又哪裡對了？總歸而言，其實各種說法都有一定的正確性，至少我至今為止還沒有聽說過哪種說法是從頭到尾完全在鬼扯的！這些說法都有一定程度的學理根據，只是當中的關鍵位置存在一些小小的謬誤，最終導致以此推論出來的解釋大錯。這些錯誤最直接的結果就是與飛機上的實際情況不符，或者無法解釋某些實際會發生的情況。

此外我還會介紹一些升力解釋法，這些說法可能並沒有錯，不過比較偏向學術抽象。這是專門寫給那些剛入門的學生們，解釋一些可能暫時難以明白的計算說法，如果您讀到那個部份感覺比較吃力的話，可以跳過它無妨；畢竟如果你本來也未曾聽聞某一種解釋方法的話，那麼那些解釋是否在哪裡存在什麼問題其實也無關緊要，只要先優先閱讀正確的解釋方法就好了！

白努利原理

Figure 1. 流傳的白努利升力原理解釋(注意氣流從綠色標註位置分開上下路徑，然後同時抵達紅圈位置)

嚴格說起來，白努利才沒有這樣解釋過機翼升力原理。不過因為語言是約定俗成的，不知是誰起的頭？但是大家叫久了也就這麼以白努利為名稱呼這種升力解釋。此種說法以上圖為基礎，氣流從機翼前緣被一分為二，並且上下兩條路徑的氣流同步抵達機翼後緣，因為上表面的路徑比下表面還長，因此上表面的流速必定比較快，按白努利方程式可知上表面壓力較低，因此機翼上下的壓力差產生了推動機翼往上的升力。

然而這種說法其實明顯的破綻實在太多，不知道為什麼能夠這麼廣為流傳？把當時年幼的我給唬的一愣一愣的，然而信了它之後卻對一些顯而易見的情況無法解釋。並且這種明顯不符合現實的有問題的說法，卻能夠被收錄在國中理化課本裡面誤人子弟！ (我國中畢業已經很久了，不知道現在是否仍被收錄？) 比方說它沒有辦法解釋飛機為什麼能夠上下顛倒過來倒著飛？(如圖 Figure 2 左上) 因為倒飛的時候，路徑較長的那一面在下面，照說這時產生的負升力應該會讓飛機墜機！還有，用這種理論去推論會發現，那些下翼面內凹的機翼產生的升力應該要更小(如圖 Figure 2 左下)，因為下翼面內凹之後路徑變長了，上下翼面長度差縮短，照理升力應該要變小，然而實際上這種機翼卻往往能夠產生更多的升力！又比方說，按照這種理論，把機翼的上表面做成凹凸波浪狀(如圖 Figure 2 右上)、或是做成像鋼盔那樣(如圖 figure 2 右下)，應該要能夠產生更大的升力，因為上表面路徑更長了；然而我們知道如果你真的造了一個這樣的機翼，只會得到更大的阻力而已，甚至做成鋼盔的樣子則可能根本飛不起來！甚至於，即便只考慮它所預設的標準情況 — 一個正常巡航中的狀態，如果你認真按照這種理論去計算飛機的升力，你會發現得到的升力甚至遠不足以托起飛機的自身重量！

Figure 2. 流傳的白努利升力原理無法解釋的問題

然而這裡必須要幫白努利做個平反，白努利其實並沒有錯，錯的是後人用他的名字冠名在他根本沒這樣解釋過的事情上。白努利的方程式是對的，至少在不可壓縮流底下是對的；那麼這理論到底錯哪兒了呢？有看過我前篇文章的讀者應該能夠很快的發現到不對勁的地方，它錯在兩個地方：其一是上下氣流並沒有同步抵達尾端，事實上依據實際風洞實驗展現的結果，上表面氣流更早抵達尾端，流速比它假設的更快得多；其二是它的流線圖畫錯了，最大的錯誤在於前緣停滯點的位置，因此我在前篇文裡有重點強調這個地方。

如果把以上兩個問題點給修正過來，再套用白努利方程式去計算，就能夠得出正常得多的結果，至少能夠解釋倒飛情況，而且算出來的升力與現實較為接近了；如果更進一步能夠分別翼表面每個部位可能加速多一點、或減速多一點的細節差異的話，那麼更能夠得到與實際實驗相當貼合的結果。這告訴我們，白努利沒錯，錯的是後面的人根本用錯了假設條件，然後再冠以他的名。

雖然修正了流場條件之後就能夠計算出正確的升力 (這裡強調「計算」，因為如果是為了「解釋」的目的，恐怕並不是一個容易理解的路子)，雖然白努利並沒有錯，但是並不好用！因為我們不能夠直接正確使用白努利方程式，因為在套用白努利之前，你必須要先知到氣流它是怎麼流的？ 然而，你怎麼樣才能知道氣流到底應該怎麼流動呢？怎麼樣才能知道流場究竟該是什麼長相呢？因此你必須先回頭重新整理解釋一遍機翼的流場；那何不直接從解釋流場開始解釋升力呢？而這就是我前兩篇在做的事情。

文氏管原理

Figure 3. 流傳的文氏管升力原理解釋

第二種流傳的升力原理解釋採用了文氏管原理，就是流體(空氣、或水、或其它一切流動物質)在流經管徑不一的管子時，會在管口縮小的地方流速加快、並且壓力降低，而在管口放大的地方流速減慢、並且壓力升高。如果將機翼的上表面看做是管道的下半部(如圖 Figure 3)，那麼上翼面的氣流就會因為管口縮減而加速，產生的低壓便會給予機翼向上的吸力。

這種理論說法乍看好像煞有其事，但稍微推敲也會發現許多它同樣無法解釋的問題。例如當機翼抬升攻角的時候(如圖 Figure 4 左)，機翼上半部的後部截面變大，會給機翼產生向下的壓力，機翼下半部的後部截面縮小，會給機翼產生向下的拉力。總體而言這時升力會降低，甚至變成負的升力而導致墜機，然而我們知道實際上攻角抬升時升力應該會增加，因此這種理論明顯與事實不符。而且這種理論還有一個弔詭的地方，若將上翼面看做是管流的下端管壁，那上端管壁在哪裡呢？然後一個有趣的事情就發生了，當你把管道邊界畫得很接近的話(如圖 Figure 4 中)，可以算出很大的升力，而當把管道邊界畫得很遠的話(如圖 Figure 4 右)，升力就會非常小；意思就是明明是一樣的機翼、一樣的姿態、一樣的氣流，只是因為我們腦海裡的意念不一樣了，升力竟然就不一樣了！意思是我們控制機翼的升力只需要用意念就可以了，這樣對嗎？

Figure 4. 流傳的文氏管升力原理無法解釋的問題

錯誤其一是文氏管規則其實只適用於「均勻管道流」，然而如同上圖所繪的虛擬管道內流場基本不是均勻的；錯誤其二其實在上面給出來的一個疑問裡已經明顯提示了，就是錯在管道的邊界！回顧這個升力理論，它的管道邊界是自己隨便畫的一條直線，問題是，你怎麼確定氣流不會越過所畫的直線呢？既然空氣根本就不照你畫的路線流動，又怎麼能期望算出來的結果是對的呢？

這裡同樣也要為文丘里做個平反，其實和白努利理論一樣，文氏管原理本身原本都是正確的，只是用這些原理解釋機翼的人錯了；如果我們將這個理論稍加修正的話，一樣也能夠用文氏管理論計算出非常接近實際情況的結果！其實廣傳的文氏管理論唯一的問題就是管道被亂畫而已，只要把管道畫正確了，這個理論其實還是很能用的。那麼管道邊界應該怎麼畫才正確呢？隨便畫一條邊界只是自欺欺人，因為空氣並不會乖乖照著你的邊界走，那麼我們就換個路子，我們照著空氣流動的路徑來畫管道邊界，這樣空氣就一定是照著走的，因為我們就是照著氣流來畫的。再來，管道不能畫的太寬，因為處在開放空間的機翼流場本身就不是個均勻流，所以管流要畫的儘量窄一點才能夠得到一個相對均勻的管流。綜合以上兩點，你會發現直接拿風洞實驗的煙線圖來參考最好了，兩條流線中間的區域正好就是一個完美的管流。按此原則，我將文氏管理論的管道流修正成下圖(Figure 5)這樣，然後你再套用回管流的速度壓力計算，就會發現一切都對了！

Figure 5. 使用流線圖的流線作為文氏管理論的虛擬管壁^[3]

最終，文氏管升力原理雖然在修正之後也能用；但是與白努利升力原理一樣，要使用這套理論的前題是： 「要先知到實際流場長的什麼樣子！」 最後你還是得去探討並解釋氣流到底怎麼吹？所以這也是我為什麼沒有選擇以文氏管理論作為切入點來解釋升力的原因！

牛頓粒子碰撞原理

Figure 6. 流傳的牛頓升力原理解釋

有一種對升力解釋是基於牛頓力學的碰撞原理，空氣就像是乒乓球一樣撞擊了機翼的下表面後彈開，這個碰撞後產生的升力就是機翼的升力，而行進的機翼就像在打水飄一樣從空氣中快速掠過，不斷以其下表面來衝擊空氣粒子並得到升力。

這種說法很簡單易懂，能解釋升力和攻角的關係，也能解釋飛機為什麼可以倒飛。但是它也存在不少缺陷，比如說按照這種說法，那麼機翼上表面是什麼造型應該都沒有任何影響才對(如圖 Figure 7)，但是在實務操作中我們知道機翼上表面對升阻力產生的影響可大了；再來就是運用這個理論計算出來的升力，和實際實驗測量出來的結果差異頗大！會造成這些盲點的原因也很簡單：這種解釋說法把空氣想的太簡單了！

Figure 7. 按流傳的牛頓升力原理，這兩個下表面相同但上表面不同的機翼，應該具有一樣的升力和阻力！

其實我很喜歡牛頓力學解釋方式，因為相較簡單易懂，而且我自己的升力原理解釋就是從牛頓粒子碰撞為起始點出發的。其實粒子碰撞說和前面提過的白努利說、文氏管說都有一個共通之處，那就是它們其實並不完全錯誤，它們的基礎規律都是對的，只是在各自不同的小地方出現了錯誤的理解認知，以致於讓整個說法變成難以自圓其說的謬論；但是只要修正了這些錯誤的地方之後，這三種說法都能夠很完美的貼合實務結果，剩下的就是哪個說法更好用的問題了。其實實際上，空氣確實就是一大堆的粒子堆積在一起組成的，這些單個單個的粒子就是單一的氣體分子。當然我們可以把空氣不要分割的那麼細，因為這樣實在很難計算，我們可以把虛擬的空氣粒子當作是沙子、BB 彈、乒乓球、或排球，反正粒子分的愈粗糙愈好計算理解，只是計算的結果偏差也會愈大；粒子分的愈細小則計算會愈貼近實際，只不過愈加難以在實務上完成計算。

所以用粒子碰撞來解釋升力是完全可行，而且可以完美解釋一切氣流現象的，只不過流傳的這種升力解釋方式把空氣粒子想的太簡單，也分割的太粗糙了。如同我在第一篇升力原理^[1]解釋的一樣，空氣粒子並不是撞到機翼之後就真的彈走不回來了，因為那個粒子的下面也有其他粒子，它們之間也會互相碰撞，然後再把它給頂回來；只要空氣粒子足夠擁擠，這件事情就會大量的發生，而這很符合地表大氣的情況。另外在微觀到分子的尺度上，空氣粒子之間互相也存在著萬有引力的互相吸引力，所以上表面的空氣粒子要被抽走的時候，它會把周圍鄰居拉幫結夥一起拖下水，這就能解釋機翼上表面的氣流行為，也能解釋前緣停滯點的位置為什麼會移動的現象。甚至那些困擾著許多流體力學和空氣動力學研究者的紊流、渦流等等亂七八糟的空氣流體現象，使用粒子法卻完全不需要對這些東西做特別處理就能模擬出來，因為這些不管這樣或那樣的流體現象在微觀的尺度上，都不過是空氣分子之間簡單的交互影響結果罷了！

那麼既然基於粒子運動的空氣動力學這麼簡單、還能夠完美解決所有有關流體行為的疑問，那麼為什麼這種理論實際上並不那麼流行呢？原因也很簡單：因為實務上的空氣粒子數量實在是太龐大了！ 我們按理想氣體理論來稍微估算一下，一個莫耳(mole)的空氣大約是 22.7 公升吧，而 22.7 公升的空氣含有多少個空氣分子呢？答案是大約 6x10²³ 個喔！那你看看一架飛機周圍的空氣應該有幾公升呢？這麼龐大的數量，得要多少超級電腦加在一起才有辦法處理啊？而且還沒說這資料處理起來得花多少時間的問題喔，只光是面對能不能夠處理這個數量的粒子就已經難以實現了！這就是為什麼說基於粒子運動的空氣動力學理論上很美好，而實務上做不到的原因了。

不過這種基於粒子的解算方法雖然並不流行，但也不是完全沒有這種應用喔！比方說如果只需要計算模擬一個很小很小區域內的流場的話就可以用，或者是要計算那種空氣超級稀薄的場域時，比方說在低軌道衛星受到空氣的影響情況等。另外還有一個很棒用途就是用來教育解說了，反正解說所需要的就只是要容易理解，並且是正確的理解，然後又完全不需要去計算任何東西，完美迴避掉了這個理論的最大缺陷！

到底是壓力差正確？還是反作用力正確？

Figure 8. 機翼表面壓力分佈^[4]

也許會有些讀者存在一個疑問，因為可能在你們以前讀過的東西裡面都告訴你：機翼的升力是來自於機翼表面的壓力，是機翼上下表面的壓力差推動著機翼往上；然而我卻說機翼的升力是來自於機翼改變了氣流的方向，是改變氣流的反作用力給予機翼向上的力！那麼究竟哪一種說法才是對的呢？到底是壓力差的解釋不對，還是反作用力的解釋錯了呢？

其實這兩種說法沒有誰對誰錯，它們都是正確的，而兩種說法其實解釋的是同樣的東西。先說說壓力吧，機翼下表面的高壓力往上推擠著機翼，但難道同樣的壓力就不會往下推動下面的空氣更往下嗎？難道除了機翼受力被推擠以外，推擠它的空氣就是文絲不動的嗎？同樣的，機翼上表面的低壓區難道只會吸引下面的機翼往上，而不會同時間把更上面的空氣也往下吸嗎？所以當機翼的上下壓力差形成，這些壓力推拉著機翼的同時同樣也在推拉著旁邊空氣，只要下面的壓力大於上面、或者上面壓力小於下面，空氣就會被推拉吸引而改變方向往下走。你可以理解為氣流形成了壓力差，這個壓力差去推拉機翼而產生升力，其反作用力使氣流向下折向；你也可以理解為機翼去推拉了氣流，機翼施加在氣流上的力以氣壓力的形式存在，這些力便推拉了空氣，使氣流折轉向下，而其反作用力施加在機翼上成為升力。

最後會發現兩種說法其實都是正確的，互相不排斥，甚至實際上兩種說法互為因果、互相伴隨，而具體採用哪種理解方式全看解釋者的主觀意識以什麼為主體。很顯然的，我的系列文章選擇了以牛頓力學為主觀視角，原因是我認為從這個角度去理解應該更為簡單容易而已。因為如果要以壓力差來作為解釋的核心，那麼首先就得建立在已知流場的情況下，於是還是避不過「空氣到底怎麼流的？」這個問題，而多少關於升力解釋說法的謬誤就是來自於對這個關鍵問題的含糊呢？於是我選擇了另一個解釋方法，直接先來探究「空氣怎麼吹的？」然後再用簡單的牛頓力學去解釋升力，重點就是放在「容易解釋並理解」。

當然這並不是在否定以壓力為主體的升力解釋，因為一個東西好用或不好用，最終還是要看具體的用途而定。比方說在應用的角度下，壓力的視角可能更加實用，因為只需要在機翼表面佈滿足夠多的壓力測量管，就可以量出在機翼表面的壓力分佈，可以計算出非常準確的受力分佈；相反的如果要用牛頓力學去解算升阻力的話，要怎麼測量空氣的流動方向和質量呢？不是只要測機翼表面上的空氣就好了喔，讀過我第一篇升力原理^[1] 的讀者就知道，這大概是要把整個風洞的空氣都要測量過一遍然後加總才行了！所以壓力分佈的觀點在實務上更加簡便好用，但是牛頓力學的觀點在解釋上更加容易說明理解。

環流計算原理

Figure 9. 環流升力理論^[5]

有一種對升力的解釋是從環流的角度著手的，當均勻的氣流吹過一個在垂直方向旋轉的氣旋時，兩股流場疊加在一起就會產生升力出來。不過說實在的，這種解釋方式因為有點過於深奧抽象，所以一般人應該並不容易聽聞這種解釋說法，可能只有就讀了相關科系的學生才會接觸到這種環流理論吧！

其實環流理論雖然看似完全不同於我之前所介紹過的各種升力理論，然而它們其實並不衝突。觀看環流流場，也會發現原來的均勻氣流被環流給改變行進方向了，所以其實追根究底，環流的升力核心來源還是來自於改變了氣流方向。再回顧我在介紹機翼剖面氣流的那篇解說，機翼上表面的氣流加速了、下表面氣流減速了、尾部氣流向下了、頭部氣流向上了(如圖 Figure 10)，你看這機翼其實不也是產生了一個環流嗎？只不過它產生的環流沒有環流理論所展示的環流那麼完美而已。如果要說機翼製造了環流於是產生升力那也是可以，就如同前面提到的壓力和反作用力的解釋關係那樣，就只是著眼立足點和解釋方式的差異而已。所以說用環流理論來解釋升力是可行的，而且環流理論也是廣泛被學術界所認識和使用的理論，也具有足夠的正確性和可用性。那麼既然環流理論其實本身並沒有什麼危及到認知正確性的問題，又為什麼這種理論沒有被廣泛用來解釋升力呢？其實也就只有兩個原因：較為抽象難理解、並且不容易套用於現實情況！

Figure 10. 機翼在氣流中實質產生了一個環流

如果考慮的是實際的流場，最適合用環流理論來計算的大概只能是棒球、BB 彈這類飛行物，而如果要計算實際的翼型，就會需要先找到一個效果與這個翼型相當的等效圓形均勻環流，然後才能計算；問題是如何知道一個任意形狀它究竟等效什麼樣大小、轉速的環流呢？就算真給你想辦法匹配了一個適合的等效環流，這個環流也往往太過理想化，也無法表現出機翼除了升力之外的其他特性，例如機翼的阻力和轉動力矩等，好像環流理論就只能拿來計算升力而已，這就是為什麼我說環流理論實用性比較低的原因了！

那麼環流理論為什麼還會存在，甚至能廣泛普及在學術界呢？這就要提到環流理論的最大優勢和用途之所在：它可以用純數學手段來解算！ 壓力分佈和白努利方程主要是對實驗比較友好、牛頓力學法容易被解釋和理解，而環流理論既不容易理解、也不貼近現實，但是它可以讓研究員們用純理論數學的手段來解析流場！

結尾

以上就是我對目前所聽聞過的對於機翼升力原理的各種解釋，它們其實並不是完完全全的謬論。我具體分析了它們錯都錯在哪裡，也說明了如何修正其中錯誤的地方之後成為正確理論的方法。那麼你還有聽過什麼更奇怪的升力原理解釋呢？

1. 翼型系列 1：機翼升力原理

2. 翼型系列 2：機翼流場現象

3. Wikipedia: 升力

4. 【物理揭秘】飞机机翼上的升力是怎么产生的？

5. Kutta-Joukowski Lift Theorem

翼型系列 2：機翼流場現象

Sat, 18 May 2024 22:24:52 +0800

這篇是接續前篇「翼型系列 1 - 機翼升力原理」 ^[1] 的續篇，繼續來探討氣流到底在機翼上面發生了什麼事？以及這些現象如何影響機翼的性能？目的是讓讀者能夠了解為什麼機翼要被設計成那些奇形怪狀的真正原因，進而有能力去「看懂」機翼，甚至能夠知道如何去調整機翼性能的方向。

上下表面速度差

Figure 1. 機翼上下面氣流速度差^[2]

當機翼將空氣流向偏折往下的時候，氣流在機翼上下表面的速度是不一樣的，流經上翼面的空氣會被加速，而流經下翼面的空氣會被減速。從上圖的實驗截圖中可以很明顯觀察出來，原來在一開始排排站一起的空氣，到了後面的時候，那吹過上翼面的空氣都已經離開機翼尾巴了，而這時下翼面的空氣才跑到大約機翼中間的位置而已。

雖然說實際上並不一定是下翼面氣流到了中間的時候，上翼面氣流就一定剛好到尾端，因為上下翼面的流速實際差多少都和很多條件有關，例如攻角、流場氣流速度、以及使用的翼剖面形狀等等。但是上下翼面的流速確實存在差異，並且通常不會同時抵達尾端。這個實驗結果直接打臉了滿大街那告訴你上下翼面的空氣同時到達尾端，但是上翼面路徑比較長所以跑的比較快的鬼扯說法。如果真的按照這種鬼扯的假設，套用伯努力公式實際計算，會發現得出來的升力大小可能遠遠抬不起飛機的重量；並且這種假設也無法解釋為什麼飛機可以上下倒過來飛？

但是流經上翼面的空氣為什麼會被加速呢？簡單的結論是因為上翼面的壓力比較低，所以把空氣給用力抽過去了；相反的下翼面壓力比較大，所以給流經下翼面的空氣一個推阻減速的作用。我想可能有不少人並不能夠直觀的理解為什麼上翼面會減壓增速、下翼面會加壓減速的這個部份，為此我們不妨先看一個比較誇張的情況來理解。

Figure 2. 機翼背面低壓拉動前方空氣

上圖左上(Figure 2 左上)的情況基本就是一塊平板直挺挺的擋在那裡，氣流直接吹上去堵在左邊，所以左邊壓力會增大，氣流也會被減速，這應該很好的直觀理解；右邊則是一個大空洞，這裡會形成一個低壓區域，這個低壓區域就會把上下吹過的空氣往裡面吸過來，這應該也很可以直觀理解；並且剛剛才被板子用力擠壓，才剛艱難越過板子兩端的高壓空氣，這時再碰上這個低壓區的用力吸引，突然高壓釋放的加速效果就會非常明顯。現在若我們把板子稍微傾斜一點(Figure 2 右上)，使它不那麼垂直，那麼情況會有差別嗎？結論是大體現象仍和板子垂直時一樣，只是流場細節開始有些不同。上下的氣流開始不那麼對稱了，稍多一點的氣流傾向往下流動，並且在流出板子下端之後比較不容易被抽回板子背面，而被抽入背面低壓區的氣流中，來自上端氣流的比例增加了。再繼續傾斜平板使攻角愈來愈小(Figure 2 左下)，這些同樣的現象依然同樣的在發生，只是影響效果愈來愈小。直到攻角零度的時候(Figure 2 右下)，上下翼面沒有任何差異，沒有被加速也沒有被減速，也沒有增壓或減壓。

這就是我對於為什麼上翼面會形成低壓區，並且氣流會被加速的淺顯白話解釋了，同樣的下翼面氣流遭受機翼下翼面的阻力阻擋，所以下面的空氣就被增壓，它會在水平方向減速，並被向下推擠加速。

上表面氣流分離

Figure 3. 上翼面氣流分離(失速)^[2]

空氣氣流流過機翼上下面時，都會沿著上下表面而吹過，但是兩邊的機制不太一樣，並且上翼面的氣流比較難維持。經過上翼面的氣流之所以能夠貼著機翼上表面走，主要受到兩種現象的影響，第一種就是前面說過的上翼面低壓，這個低壓不只把前面的空氣吸過來加速，也會把上面的空氣吸下來 (當然也會把後面的氣流往回吸，所以上翼面氣流在過了最低壓區域之後又會慢慢減速，不過平均還是快於下翼面就是了)；第二種就是康達附壁效應(Coandă effect)，會讓氣流擁有貼著物體表面走的趨向。

但是這兩種效用都有一定的極限，不可能無限的吸附空氣順著它流，當攻角增加到大於某一個程度以後，上翼面的氣流要繼續貼著表面走就會過於困難，氣流無法再繼續附著在上翼面表面，從而會分離開來。這個現象稱為「氣流分離」(flow separation)，用在機翼上又有一個專有的稱呼叫作「失速」(stall)，這個氣流分離的現象對機翼的設計使用都非常重要。我們知道機翼的升力來自於上下翼面導引氣流所得力的加總，當發生氣流分離現象時，上翼面將無法再有效的把空氣吸引改變流向向下，因此會直接喪失掉上翼面的升力。你可以想像本來兩個人抬著一整架飛機的重量在飛，突然一個人消失了，肯定得讓飛機重重摔下來。因此我們一般會很重視這個即將喪失升力的失速攻角，而機翼翼型的失速攻角也成為衡量這個翼型好壞的一項重要指標數值。

當氣流分離的情況嚴重時，如同上圖(Figure 3 圖右)那樣，此時不只上翼面氣流幾乎從頭開始就沒有再附著在機翼表面，連下翼面的氣流在流出尾端後都被往上吸附而捲上來。我們在機翼升力的原理那裡說過，機翼產生升力的原理就是從改變氣流流向而來的作用力，那麼在氣流分離現象嚴重的時候，不只上翼面不再能夠有效吸附氣流往下，甚至連下翼面好不容易折轉的氣流都被大量捲上來。這時候就會形成一個機翼幾乎無法有效偏轉氣流，反而還背了個低壓的大漩渦；幾乎無法有效產生升力，只產生了強大阻力的極不利現象。

相較於上翼面要小心呵護氣流，下翼面就寬鬆隨意的多了，畢竟除非氣流可以吹斷機翼，否則不管攻角怎麼大，氣流在下翼面也只能被老老實實的壓著貼著機翼表面走！

既然如此，上翼面吸附氣流比較吃力，下翼面則隨便怎麼樣氣流都得照著跑，那能不能將機翼形狀設計成上面坡度比較小、而下面坡度抖，如同下圖(Figure 4)這樣呢？答案是一般來說沒有辦法，因為我們的機翼不是無限長，總是要有個結束，而這樣機翼的上下面將無法會合到一起，到了尾巴只能變成一個問題更大的截斷面。這一個陡峭的大斷面可能會產生更大的問題，造成更大的渦流低壓區，變成一個強大的阻力！ (但也不是絕對沒有人做成這樣，這部份等以後有機會談到機翼高升力裝置的話，會再回來探討這種設計)

Figure 4. 下翼面坡度大、上翼面坡度小的理想機翼(若不考慮機翼總有結束的地方)

氣流分離的條件

上翼面氣流分離的基本原因，就是上翼面的氣流無力再繼續跟著上翼面彎曲的角度，因而脫離了上翼面表面。通常來說，氣流分離的條件與攻角有關，當機翼不斷抬高，上翼面氣流要繼續貼著陡峭的翼面行走就會愈來愈困難，當攻角抬高到某個臨界值之後，上翼面的氣流就會開始大量剝離機翼表面，這個攻角被稱為「失速攻角」。

但影響失速現象產生的臨界點除了攻角的大小之外，還和一些其它因素有關，例如氣流速度。當機翼所處在的氣流流速降低的時候，發生失速的攻角會被延後，機翼能抬到更高的攻角時才會發生失速；如果氣流流速足夠低的話，就可以把攻角抬得高高的仍然保持氣流不分離；相對的，當流速愈來愈快的時候，失速攻角會降低。這就像是很多學校的樓梯都有那種 180 度的大轉彎，當小朋友們為了搶什麼東西而飛速下樓的時候，就很難一直貼著樓梯內側的欄杆走，即便用手勾住樓梯欄杆依然吃力，但若放慢速度慢慢走，則貼著欄杆走便非常容易；而氣流在流過陡峭的上翼面斜面時也是這樣。

還有其他的因素也會延後或提前機翼的失速攻角，例如機翼的大小。當一個機翼的前後距離(弦長)很長的時候，上翼面氣流要一直沿路貼著走的難度就會增大，導致容易走一走就撐不下去而分離，相對的當機翼前後長度較短的時候，氣流要貼著走完全程的難度就會降低。另外當機翼處在一個氣體不斷膨脹的環境中時，上翼面的空氣就會受到不斷在膨脹的氣體推擠，會更容易貼緊上表面，更不容易發生分離。這就像是雖然小朋友們單獨下樓梯的時候不容易時刻緊貼在樓梯內側欄杆，但若是好多同學們一起推擠著下樓的話，內側的同學通常就能夠很好的緊貼著欄杆走，因為就算他想要離開，也會被周圍其他同學給推回來。

總結一下，上翼面氣流的分離通常會帶來負面的影響，而具體導致氣流分離的發生條件和翼剖面形的設計、以及在氣流中的操作狀態有關。影響上翼面氣流分離的幾個主要條件約為：

機翼的攻角：攻角愈大時，上翼面坡度愈陡峭，愈容易分離。
氣流速度：機翼所處在的流場流速愈快時愈容易發生氣流分離，反之流速愈慢愈不容易分離。
機翼弦長：機翼前後距離愈大，氣流愈不容易從頭到尾緊貼不分，因而愈容易發生分離。
機翼彎曲弧度：機翼上表面愈彎曲，愈容易產生陡峭的坡度，氣流也會愈容易分離。
翼前緣形狀：不適合的翼前緣形狀會在前期大量消耗氣流動能，導致上翼面氣流容易無力再緊貼機翼表面，因而容易分離。
流場條件：處在一個空氣不斷在膨脹的流場，上翼面空氣會因為膨脹推擠的緣故而更容易貼付表面，因此不容易分離；反之當空氣不斷在壓縮而縮減體積時，氣流就會更容易發生分離。

前緣停滯點

Figure 5. 翼前緣停滯點^[2]

Figure 6. 翼前緣停滯點：上為常見的想像位置，下為實際的位置

從上圖風洞實驗的照片(Figure 5)還可以發現一個現象，上下氣流的分離點可能和許多人想像的不太一樣！均勻的氣流從前面吹過來，因為機翼的阻隔而被分成上下兩部份，這個在機翼面上，分隔了上、下氣流的中間那個位置，稱為「停滯點」(stagnation point)。也許在很多人的想像中，停滯點的位置就是在機翼的最前面(Figure 6 圖上)，而且很多機翼的解釋、甚至有些教科書都是這麼畫的；然而這是一個天大的錯誤，真正的停滯點其實是在往後移動了一小段距離的下翼面前端(Figure 6 圖下)；當然如果是負攻角的話，停滯點就會跑到上翼面前端去。

為什麼真實的情況會與想像中有這點差異呢？為什麼空氣不應該是在最前頭的地方被分開呢？答案是在一推擠、一拉扯。我們前面說到上翼面空氣會被加速，所以會從周圍拉扯更多空氣進來補位，否則空氣被拉走不就得真空了？ (先假設空氣還沒到會有壓縮效應的程度) 同一種解釋的另一種說法是上翼面形成的低壓區也會吸引牽引四周的空氣進來(見 Figure 7)，所以上翼面再上面的空氣被往下拉、後面的空氣被往回拉而減速，前面的空氣被往後拉而加速，當然也把一部份本來看起來該往下翼面走的空氣給拉過來往上走了。另外一邊，在下翼面的空氣被機翼推擠(見 Figure 7)，氣流在水平方向減速了，空氣壓力增加，往後塞車的情況下使得大部份氣流被往下推擠，當然也有一部份的力被往前推擠，就把一部份本來看起來該走下翼面的空氣被擠出去往上走了。於是翼前緣這些許多人直覺上以為該往下走的空氣，就在一邊被下翼面增壓推擠、一邊被上翼面低壓吸引之下，往上走了，從而使得真正的氣流停滯點下移到了真正的那個位置；而且如果攻角繼續增加，這個停滯點的位置也會繼續後移。

Figure 7. 翼面上下的氣流推拉趨勢

翼前緣

前面提到的那個發生在翼前緣的，稱為停滯點的奇異小知識，其實對氣流的影響是關鍵性的。前面示意圖故意選用了平板形狀翼剖面，你會發現從翼前緣到停滯點之間的氣流會需要艱難的急轉彎翻越這個翼前緣，這其實會產生一個討厭的後遺症。我前面說到上翼面抓住氣流比較吃力，當攻角大過一個程度之後就會抓不住氣流，使得上翼面氣流分離，產生失速。然而氣流之所以會分離的根源原因其實在於上翼面的氣流能量不夠了(動壓損耗)，才因此沒有足夠的動力繼續去貼附翼表面，而氣流之所以會喪失足夠的能量，其實就是氣流在與機翼表面的摩擦中消耗了。

在了解上翼面氣流分離的根源原因在於氣流的與機翼表面的摩擦消耗之後，我們再回來看看平板翼的前緣，氣流在這裡急遽的急轉彎轉向，有騎過車或開過車的讀者應該可以感受，這是一個劇烈的動能消耗。這個消耗會導致一個後果，那就是上翼面的氣流將會更難維持貼附，可能幾度的攻角就能導致發生失速，而相比於其他那些比較「常見」的翼剖面形狀，有些低速翼型甚至可以撐到 20 度不失速。

既然知道了翼前緣對氣流的深刻影響，那麼如果能改善翼前緣劇烈消耗氣流動能的現象，就可以延緩上翼面氣流分離的門檻，改善翼型的性能。其中簡單的做法就是將翼前緣做成圓弧形(或橢圓形)，就能讓氣流轉向更平緩(如 Figure 8 圖中)。頭部圓弧的弧度大小也會影響氣流在這地方的行走流暢度，從而影響機翼形狀的性能，圓弧做的太小，就會讓機翼表現更加接近平板的尖銳前緣，增加氣流從前緣翻過的消耗(如 Figure 8 圖左)；圓弧做的太大(如 Figure 8 圖右)，就會帶來機翼厚度增加的副作用，此外在停滯點位置也會更像一個大的牆壁一樣，強迫更大範圍氣流進行 90 度轉向，同樣也會增加消耗。

Figure 8. 不同程度圓角處理的翼前緣

機翼弧度

Figure 9. 弧狀彎曲的機翼

經過前面針對空氣氣流與翼前緣形狀的解釋後，也許有些聰明讀者舉一反三說：「啊那我懂了，機翼的形狀就是為了讓空氣可以更順暢的轉向嘛！那又為什麼前緣要做成圓形呢？我直接順著氣流的流動趨勢做成像上圖(Figure 9 左上)的形狀不是效果更好嗎？」如果說平板不利結構強度和空間利用，那就給它一個厚度，然後做成上圖(Figure 9 右上)的樣子就好了。

其實這個方案還真的有用，再把前後做成尖銳狀的話就更完美了！尖銳前緣正好如同都江堰一樣順暢的將氣流一分為二，沒有前面大圓頭產生的氣流 90 度大轉彎；機翼前段不是平直正正的擺放，而是參考前面的風洞實拍，順著氣流進來的自然角度擺放，完美避免下面氣流要被迫翻越尖銳前緣的問題；翼型中段再用一個弧度設計，將氣流順暢的逐漸改變方向，而不是用一個直挺挺平板直接叫氣流轉向。這樣子做出來的翼型就是非常完美的翼型，不僅對氣流的不必要擾動最少、阻力最小，還能夠最高效的導引氣流改變方向。

然後我們把這個翼型放平來看(Figure 9 左下、右下)，有沒有一種豁然開朗的感覺？這不就是常見機翼剖面的雛型了嗎！這就是為什麼我們通常看到的機翼剖面形狀都是帶有弧形的原因了，與什麼伯努力什麼的完全沒關係，單純就是一個弧形可以更順暢的引導氣流轉向而已。有些翼型看上去比較難看穿這種設計思路，因為它的下翼面是平的，只有上翼面帶有弧度而已(如 Figure 10)。這種翼型其實可以看做是一個厚度漸寬再漸窄的對稱翼，再疊加上一個彎曲的弧度之後的結果，恰好使下翼面成為平面。而其實這個平面是精心計算設計後的結果，目的就是為了讓下翼面剛好是個平面，為的是這樣比較方便加工製造而已！

Figure 10. 下翼面做成剛好是平面的帶弧翼型

圓弧前緣或尖銳前緣的選擇

Figure 11. 銳角前緣和圓角前緣偏離最佳攻角時的氣流反應

現在我們再回顧一下前面才提過的翼前緣形狀設計。我們在前面將翼前緣做成圓弧形，是為了避免像平板那樣使氣流必須翻越尖銳的前緣，然而現在我們學會將整個前段灣個角度下來主動適配氣流方向，這樣看起來完全不需要採用圓弧的前緣，完全避免圓弧前端會給停滯點附近氣流帶來 90 度大轉彎的缺點，採用尖銳的前緣設計更能夠令氣流的損耗減到最小；但是為什麼這樣子看似完美的形狀卻少見被採用在實際的機翼上呢？

這是因為這種彎曲翼面加上尖銳前緣的翼型只有在特定攻角才能達到最完美效果的緣故，一旦攻角偏離了設計上的最佳角度，如同平板翼那樣導致氣流必須翻越尖銳前緣的情況同樣會出現 (如 Figure 11 左上、右上)。然而作為飛機的機翼，飛行姿態隨時在變化、氣流角度隨時都在變化的情況下，通常我們更希望機翼對氣流的接納度能夠存在比較寬一點的操作區間，至少不會稍微抬個頭、低個頭就給你來個失速警告！在此前提下，這種只在特定攻角才有最佳效果、離了最佳攻角就容易失速的形狀顯然就不是個好的設計，而這也是為什麼我們平常看到的飛機(超音速飛機除外)，它總是採用圓頭翼剖面型的原因了！

但是換個角度，如果發現在你計劃中的使用情境裡，氣流總是只會在一個設定的特定攻角吹進來的話，那麼上面這種尖頭的弧形翼就會變成一個效果極佳的形狀。

翼後緣

和翼前緣的情況不同，在機翼尾端我們會想阻止下翼面的氣流翻到上翼面去，於是所有機翼形狀的尾巴幾乎毫無例外的都做成尖尖的。

看下圖所示的幾種翼後緣形狀，如果翼後緣和前緣一樣做成大圓弧(Figure 12 左上)，那麼下翼面的氣流就會有向上翻越的趨勢，而下面氣流往上翻的這個趨勢，顯然對我們設計的機翼想要將氣流導引轉向向下的目的不利。如果將翼後緣的圓弧直徑縮小(Figure 12 右上)，那麼下翼面的氣流翻越阻力就會增加，翻越的過程會大量消耗下翼面氣流的動能，從而容易使下翼面氣流分離，就和我們前面解釋上翼面的氣流分離一樣；不同的是上翼面的氣流分離是我們所不悅樂的，而下翼面氣流的分離卻是我們所希望的。如果翼後緣的弧形直徑非常小，那麼下翼面氣流甚至還未完成後緣的翻越就分離了(Figure 12 左下)，這就是為什麼機翼的後緣總是做成尖尖形狀的原因(Figure 12 右下)，因為尖頭的形狀可不就可以看作是一個直徑無限小的圓弧嗎？

Figure 12. 不同程度圓角處理的翼後緣

倒飛

Figure 13. 倒飛狀態的機翼

至此為止我們看的都是正向設計的機翼機翼擺出的攻角都是朝向產生升力的方向，甚至那種帶高彎曲度的機翼也是在這樣的條件之下設計出來的形狀。但是眾所周知，飛機也能翻過來倒飛，那麼這時機翼的流場會是什麼樣子呢？

如上圖(Figure 13 圖上)所示，對稱的機翼是正著還是倒著並沒有什麼差別；上圖(Figure 13 圖中)則是為了正飛而設計的翼型，因此翻過來飛之後的升力效果就不太好；但上圖(Figure 13 圖下)則是另一個極端，它偏轉氣流向下的能力不佳，尾巴還往上勾起來，原來為了特定攻角下引導氣流的翼前緣形狀現在反而變成導致氣流分離的好發地帶，整體產生的升力成果不佳，又讓氣流在中間彎彎繞繞增加了阻力，因此飛行效果最差！但無論如何，只要機翼仍然能夠導引氣流轉向，它就能產生升力，至於產生升力的效率如何？副作用阻力如何？這是另外要去討論優化的問題，而與產生升力的原理無關且不矛盾。

這一切都符合我提出的解釋，也符合我們在現實世界觀察到的事實，飛機確實可以上下倒著飛，只是倒飛時的效率不好，需要抬高更多攻角才能夠產生足夠的升力支撐飛機重量，並且飛行阻力也會增大，因此一般飛機都只有在必要的時候才短暫的進行倒飛。

總結

經過本文的解說，我們能夠理解一些發生在機翼上面的重要氣流現象，明白氣流在每一個地方會受到機翼外形產生什麼樣的流動效果，以及機翼剖面形狀各個部位的形狀如何影響著氣流，至此我們甚至有能力從無到有手搓一個全新翼型出來了！這樣下回當你再從哪裡看到機翼剖面形狀的時候，你就能夠看懂它，也有能力向別人詳細解釋它的形成，和每個部份為什麼會長成那個形狀的實際原因；至少不會再覺得翼型就是個不解的迷之形狀，透過完全不清楚的魔法來產生升力了！而至此也乎應了我在前篇^[1]所說：機翼產生升力的核心原理和那個奇妙的形狀完全沒有關係，升力的真實來源在於引導氣流轉向而來，而那個奇妙的形狀只是為了使流場更順暢、更加高效的引導氣流產生升力的最佳化調控結果。

作為一個總結，我們再一次試著回顧並濃縮本篇所講述的各項，然後嘗試自己手搓一個屬於自己的翼型吧！

設計一個一個全新的翼型，首先我們需要決定「機翼弧度」和「厚度分佈」：
- 機翼弧度就是機翼導引氣流轉向的路徑，你可以自己嘗試畫一個，具體取決於你想要用一個什麼樣的路徑來引導轉向氣流？以及要轉向的角度有多大？畫完弧線後，將它轉個角度放平就是你機翼的翼弧形狀了。
- 機翼厚度分佈圖做圖原則就是在維持儘量流線的形狀下，依照你對翼內空間大小的需求而控制厚度。需要空間大一點來放油箱、放裝備、放骨架結構的，就把厚度畫大一點，激進的話可以把頭尾都更加膨脹，形似橄欖球；保守一點就畫的更纖細一點，形似紡錘。
將機翼弧線和機翼厚度合併之後，就得到了翼型雛型。
用一個圓將機翼前緣做成圓頭，採用的圓半徑具體依據你的機翼厚度、和你對機翼攻角操作裕度的考量而定；或甚至激進一點的話也可以保留尖頭。
這一步驟不是必須的，但若你願意的話，可以回去前面步驟調整機翼厚度分佈和翼弧彎曲度，使下翼面剛好形成一個平面。這麼做的好處是當你要實際使用這個翼型打造機翼的時候會比較容易方便，但若你所需要的是絕佳的性能表現的話，那麼也無需多此一舉。
至此我們從無到有自己產生了一個全新的翼型。還有餘力的話就送去進行風洞測試，然後繼續微調最佳化。最後給你自己的新翼型起一個名字，把它使用在你自己的飛機上吧！

Figure 14. 翼型的誕生

1. 翼型系列 1：機翼升力原理

2. how wings work? Smoke streamlines around an airfoil

翼型系列 1：機翼升力原理

Sun, 12 May 2024 00:35:02 +0800

飛機為什麼能飛起來？機翼為什麼能夠產生升力？這已經是一個很老的問題了，也早已有無數前人為了這個問題做出解釋，對一個從小就喜歡飛機的我來說，從小到大都看了不少各種說法。那為什麼我還要再寫一篇解答呢？因為我覺得那些我看過的解答都不夠理想。

其中大半關於機翼升力的解釋存在謬誤，甚至連當時國中理化課本對此問題的解釋也不正確，這些百家說法誆的童年時的我不只看了不懂，反而心存更多疑惑；而那少部份學理正確的解答又多半太過艱深，如果要用來對普通人作為升力效應的解釋，反而更容易加深玄幻。甚至有些文章博主或節目主持人在一知半解之下乾脆出口了「機翼升力的原理過於奇妙複雜，甚至至今沒有科學家能夠完全解釋！」這種不知從何而來卻口耳相傳的話語，把一個簡單的物理現象活活蒙上一層紗，給普通人對飛機升力的印象從玄幻又加上了魔法！

因此在這裡，我將要用我的方式重新解釋飛機的機翼之所以產生升力的原理機制，而且我要在保有正確性之餘，儘量用淺顯易理解的方式解釋給你。如果你也對機翼的升力原理感到好奇，或者像小時候的我一樣看了一堆機翼原理解說卻仍然帶著疑惑與不解，那麼請接著看下去……

升力核心原理

機翼產生升力的原理並沒有那麼複雜，相反的實在太過於簡單。坊間一堆人會對著飛機機翼那奇妙的剖面形狀來論述一番，然而這些神奇的剖面形狀雖然對升力的產生有提高效率的效果，卻與升力的產生本身沒有關係，也不是產生升力的必要因素；實務上，就算你隨便拆下一扇門版來當成機翼使用，它依然產生升力。探究氣流在吹過機翼之後為什麼就產生升力的問題，升力產生的根本原因其實就是：「機翼偏轉了氣流，改變了氣流的方向。」換句話說，機翼對氣流施加了力量從而使得氣流向下發生偏轉，而受力偏轉的氣流反向給機翼施加了一個等量的反作用力，此即為升力的來源，同時也是阻力的大宗成份。

Figure 1. 氣流導流片，從左圖一整排導流片，中圖較為稀疏，到右圖只剩一個導流片

如上圖(Figure 1 圖左)所示，想想看，管道裡的氣流平行從左往右吹過去，在經過出口的一排葉片之後，氣流會發生什麼變化？是不是氣流在經過這排葉片之後，就幾乎全部被偏轉向下了呢？像這樣的流場裝置其實在大家的生活裡經常可以看到，因為這就是冷氣機出風口的導氣葉片，大家都見過，也都很容易直覺理解。

你覺得管道導氣葉片和飛機機翼相差甚遠嗎？那如果我們拆走一些導氣葉片的話，你覺得氣流會有什麼不一樣嗎？如上圖(Figure 1 圖中)減少了導氣片的數量，也許因此導致導氣轉向的效果降低了，但是這排葉片的導氣效果依然存在，而且偏轉氣流的原理機制依然是一樣的。繼續減少導氣葉片直到如上圖(Figure 1 圖右)只剩下一片葉片，看這不就是和一片機翼一樣的東西了嗎？只有一片葉片，它仍然具有折氣的現象，即便這個現象會弱化到不太容易明顯的觀察出來。

Figure 2. 飛機機翼剖面形狀^[1]

現在我們回來看看另一張圖片(Figure 2)，從飛機側面看過去可以明顯發覺它的機翼並不是呆板的平板一片，而是帶點神奇弧度、型似剖半水滴的形狀，這就是我們通常所說的機翼剖面形狀。然後一堆人就會拿著這個形狀，用各種似是而非的說法去試圖解釋升力的原理，但是因為理解錯誤，所以怎麼樣都會有一些無法解釋的盲點，最後只好歸因於魔法了！

所以我們首先要跳脫這個框架陷阱，這裡我就直接告訴你，升力產生的原因和這個形狀並沒有關係！你可以把這個形狀上下翻倒過來倒著飛，它一樣能產生升力；就算再把它前後方向也轉過來顛倒著頭尾來飛，它依然會產生升力。你甚至可以把它換成其他各種奇怪的形狀，只要它還具有導流轉向的作用，它就能夠產生升力；至於產生升力的效果大或小、帶來的副作用如阻力是多或少等等，那就是另外的問題了，是流場效果最佳化的問題，而事實上那才是為什麼我們通常看到的機翼剖面會長成那個樣子的真正原因。

以牛頓力學解釋

Figure 3. 攻角(AOA)

前面說過，機翼產生升力的最主要原因在於改變了氣流的方向，因此機翼這片板子必須要和氣流存在一個夾角，有了這個角度的存在，機翼才能折彎氣流的行進方向。這個夾角就被稱為「攻角」(Angle of Attack (AOA))，正的攻角表示機翼往上抬起，而負攻角表示機翼往下低頭。

Figure 4. 將空氣簡化為法碼，受機翼影響改變流向

一個帶攻角的機翼如何偏折空氣而產生升力呢？我們先將機翼上下的兩團空氣簡化為上下兩個質量塊，也就是圖中的法碼 A 和法碼 B。假設它們質量各為 1 kg，並以 10 m/s 的速度衝向一片帶有 30 度攻角的機翼。

A 法碼很容易理解，它撞擊到機翼的下表面後被機翼偏轉了方向，改為往下 30 度的方向繼續前進。這裡要注意一點，我們為了簡化的緣故而用法碼代替一坨空氣，因此它不是像乒乓球打到球拍那樣反彈，而是在碰撞之後偏折為和機翼同一個方向離去。離開了機翼的法碼速度為 10 m/s 並方向為 30 度往下，我們可以把它分解為水平速度 0.866 m/s 和垂直的速度 0.5 m/s，我們可以藉由牛頓運動公式 F = M*V2 - M*V1，算出機翼受到了向上的升力 5 N 和向後的阻力 1.34 N。

機翼下表面偏轉了空氣所產生的升力就是機翼全部的升力了嗎？並不是，因為我們容易忽略了機翼上表面也能夠吸引氣流往下。機翼上表面一樣可以把空氣吸下來，這就是圖示裡法碼 B 的那部份。從機翼上表面過去的法碼 B 所代表的一坨空氣也會被吸引偏折往下，它與下表面法碼一樣往下偏折了 30 度，那麼它產生的升力和阻力也就和法碼 A 是一樣的。因此機翼最終受到的升力和阻力，就是兩個法碼對它產生的力的和，是 10 N 的升力和 2.68 N 的阻力。這個數字其實並不重要，它與實際上的數值差異相當大，因為中間我們簡化了太多的東西。不過這只是為了用來解釋最核心的原理邏輯而為之，我們後面會再把它愈來愈複雜的部份慢慢加回來。

這裡我們還要注意另外一個重要的現象。在前面的示例中我們假設的是一個超完美的情況，沒有摩擦、也沒有任何損耗，僅僅只是讓空氣轉向了而已。然而就是這麼樣一個完美的流氣轉向，它在垂直方向的加速度給我們帶來了我們想要的升力，而水平方向的加速度卻同時給我們帶來了阻力。這告訴我們在機翼產生的阻力裡面，至少有這麼一部份的阻力是伴隨著升力而產生的，不可能完全消除。我們可以花費各種巧思去減少其它成份的阻力，例如打磨光亮使空氣摩擦產生的阻力減到最低等，但對於這個因為產生了升力而伴隨出來的阻力則沒什麼好方法去阻止它，因為它之所以產生的原因正好就是升力產生的原因。若要減少這種因為升力而伴隨的阻力，則只能同步降低升力；若要完全消除這種阻力，則它必然無法產生升力！

更加接近真實空氣

Figure 5. 上下方向附近的空氣法碼其實互相都會影響著彼此

目前為止我只是解釋了最核心的升力原理，但是如果照這麼計算的話，就會發現和現實有很大的落差，這是因為原理雖然是這個原理，但是真正的空氣卻也並不是硬梆梆的兩塊硬物。那麼為了解釋發生在機翼上面的各種空氣流體現象，我們就得一步一步更加了解真實的空氣。

真實的空氣肯定不是一坨硬物，空氣其實是一大堆自由活動的粒子，也就是空氣分子。但是空氣分子實在是太小了，干擾我們對空氣流動的理解，我們可以把它想成是大一點的沙粒顆粒。這些顆粒之間彼此具有一定的吸引力，所以如果你把一部份空氣粒子拉走了，旁邊會有一部份粒子也像是被黏著一樣跟著跑，然後更遠的其他空氣粒子就會想過來補充這個空出來的空間。空氣顆粒之間雖然互相吸引，但如果距離太近的話它們也會互相排斥，所以如果你把一部份空氣粒子捏在一起，它們就會很難受的想推開你的手往外衝，只要你手一放開了它們就會用力竄出去。

那麼我們把剛剛的條件，就是機翼上下兩塊大法碼的假設，更換成上圖(Figure 5)那樣上下一整排的小法碼。那麼機翼下面的法碼 A1 的行為其實就和我們之前的設想應該是完全一樣的，而法碼 A2 也因受到法碼 A1 的推擠而往下轉向，只不過這種間接影響力打了個折扣，所以 A2 的轉向效果比 A1 更少一些。後面 A3 也同樣受到 A2 推擠而轉向，不過受的影響更少，再後面 A4、A5…… 都可類推，到了 An 的時候因為距離已經很遠，所以幾乎沒受到影響。機翼上面的一整排法碼也是一樣的，B1 被吸引下來沿著機翼上表面轉向， B2 同樣受到影響但打了個折，然後 B3、B4…… 以此類推，直到 Bn 才像個沒事人一樣幾乎不受影響。最後把 A1 到 An、以及把 B1 到 Bn 的法碼們受到的力加總起來，就是更接近真實情況的機翼升力了，雖然離真正的真實情況還是有點距裡，不過只少比其前一個只有 A、B 兩法碼的假設之下是準確多了。

而這裡也解釋了為什麼法碼 A1 沒有在撞擊到機翼之後走反彈路徑，而是貼著機翼下表面走？這就是因為它被 A2 的推擠壓力給頂回去了；同樣 A2 和 A1 碰撞之後也沒有走反彈路徑，也是因為 A3 的存在而造成的。

Figure 6. 各個方向的法碼其實都會互相影響著彼此

更進一步，除了在上下方向上的空氣會互相影響之外，其實前後方向的空氣粒子也同樣會彼此產生影響和干擾，比如後面的空氣慢下來了，前面的空氣也會跟著提前慢下來、或者提前轉向；當然後面的空氣若加速跑了，前面的空氣其實也會受影響而開始加速，或者附近的空氣會開始轉向朝這裡填補進來。所以我們進一步把代表空氣粒子的法碼們像上圖(Figure 6)一樣佈滿在整個空間中，然後計算彼此互相的影響並加總，就能得出更加接近真實的結果。當然這樣的計算已經有點複雜了，不再是簡單手算就能夠應付過來的。

Figure 7. 實際的翼型風洞實驗^[2]

現在來看看這張在實際風洞實驗中拍攝出來的流線圖，它在吹氣的源頭加入了煙霧標記，使我們可以用眼睛看見本來難以觀察的空氣流動走向。圖片上面標註的 A 和 B 區正好對應了先前把空氣假設為一排法碼所表現的樣子，而 C 區也清楚的展示了空氣擾動會往氣流上游方向傳遞的特性，即使這部份的空氣還沒有真正接觸到機翼，卻已經提前開始受到影響而轉向了。尤其 C 區展現出來的現象特別重要，因為一般直覺上我們只知道上游的擾動會影響改變下游的氣流，生活上卻比較少注意和感受氣流下游的擾動使上游發生變化的這個部份。

結論

至此我們了解了機翼產生升力的原因是來自於轉向了氣流，也透過一些簡單的物理原理來示範和計算空氣的作用力。請不要太小看這樣簡單的計算，因為事實上這就是基於空氣粒子的空氣動力模擬計算雛型。然而在解釋了升力原理之後，我想讀者腦中一定會浮現出更多的問題，比如「你說升力和那個形狀沒有關係，那為什麼人家機翼要造成那個形狀？」等等。因此，下一篇我將要來繼續探討那些空氣發生在機翼上面的故事……

1. Wikipedia: Airfoil

2. how wings work? Smoke streamlines around an airfoil

人體的美感

Tue, 05 Mar 2024 00:02:27 +0800

什麼是美？我們對美感又如何評價呢？從來，只要談論到審美的話題，我們總是被教育說美感沒有標準，每個人都能有自己獨特的眼光。但是世界的現實卻告訴我們這觀念錯了，大大的錯了！至少對於同為人的人體來說，美感是有正確性與否的，是有對與錯的分別的。只不過這美感的對或錯，不是由任何人來評價，而是由達爾文來對每一個人的審美做評分；那些在美感的試卷上填答錯誤的人，將要接受無情又殘酷的懲罰！

何謂美？賞心悅目即為美；那麼怎麼樣的人體會讓人賞心悅目呢？試著回想一下，人們普遍對什麼樣的身形體態感到賞心悅目？對什麼樣的臉蛋感到愛不釋手呢？其實古希臘人的雕像幾乎就已經完整的展現出什麼樣子的人體最讓人嚮往。並且希臘雕像也告訴我們男人與女人的美是大異其趣的，若有雕成女人樣子的男體、或者雕成男人樣子的女體，都很恰巧的不會讓大部份的人覺得美。

男人與女人

我們先從簡單的來看，由男性的主觀角度出發，什麼樣的女人會使男人們心生嚮往、感覺舒暢呢？這部份大概沒什麼爭議而且有共識，乳房大的更受喜愛，如果都乳大的話，那就比較挺立的更受青睞；臀部較寬的女性較受喜愛，如果臀都寬的化，那就腰纖瘦且腰臀比恰到好處更受青睞。有沒有發現一件事，這些特徵都是和女性的生育與喂哺能力掛勾的？乳房的大小直接對應了哺乳的潛在能力，而髖骨的大小和寬度對應了承載嬰兒的能力、以及讓嬰兒的大頭能夠順利穿過的能力。這就是人體美感的核心價值，其實沒有那麼多虛無縹緲的天花亂墜，其實核心就是圖個能生好養，並且對那更能生小孩的身體、或者更能養小孩的身體更加傾心愛慕！有些看客到這裡請先別急著反駁，我知道很多人主觀意識上可能不存在這樣的想法，但是你的身體有這樣的想法；這些偏好可能大半不是直接來自你的大腦意識，而是那刻在基因裡面的深層因素在影響著你的偏好，我們稱之為「天性」。

除了乳房和臀部明顯和生育直接相關之外，對於其他身體特徵的偏好雖然不如此二特徵明顯，但其實也全部都是直指著一件事：生育價值！比方說沒有過多贅肉的身形體態告訴你她的健康狀態和身體機能良好；細嫩緊實的皮膚、柔滑茂密的頭髮告訴你她正處在年輕的生育巔峰狀態；如果男人喜歡那女人身上所散發出來的不知名的淡淡幽香的體香，這更是女人生殖相關荷爾蒙分泌旺盛的指標，那個味道的「不知名的奇妙」更是「你大腦不用認識，只要你身體能認得就行」的輔證。

其他還有一些男人所青睞的女性身體特徵與生育的直接關聯性更遠，比方說身形高挑、四肢修長，乃至於膚色的深淺、體毛的多寡等等。那是因為具有這些身體特徵的人的生存能力更高，而這樣的女性的下一代大概率會繼承這些特徵，因此與這樣的女性交配將更能夠生出具有優秀生存能力的後代。 (至少對於這位男人來說是這樣的，因為兩人合併產生的下一代比自己更優良；至於如果女性嫌棄這位男性的話，可能單純是因為對該女性來說，與他合併的下一代的品質是被拉低了！)

說完了男人之後，我們來看看女人覺得什麼樣身形體態的男人更有吸引力？我們知道女性所認為美(或稱為有吸引力)的男性，和男性覺得美的女性是不相同的，至少不會覺得有 S 曲線的男人更美，可能也不覺得細皮嫩肉的男人更能令自己小鹿亂撞。相反的，粗曠的皮膚和毛髮也許更加俱備吸引力！

對於男人的美，特別是女人眼中的男人的美，更多的成份來自於肌肉的力量、高大的身材、和更加孔武有力的外表等等，最好身形如倒三角，渾身散發睪固酮的味道。這些特質其實都反應了這個男人的生存開拓能力，是隱含著這個男人是否更有能力保護身邊女人與孩子的潛力，又或者是與獵物或敵人搏鬥，取得生存空間和資源的能力。

關於那臉上的長相

人臉的長相輪廓，可能是一個人全身上下的所有表徵之中最難解釋與生存繁衍之間連繫的特徵了。不同的長相、不同的輪廓、甚至不同五官比例，或許多少都存在我們覺得美的樣子，乍看好像真的是人人皆有所好；但若我們暫且不看那讓我們覺得美的部份，而是看看那我們覺得醜的部份的話，仍然能夠看出一些端倪。

其實人臉可以非常細微的傳遞出一個人的身體狀態，就連這個人全身上下都很好，只是今天病了、或倦了，我們都能透過對方的臉部細節察覺出一些情況。當然通常來說，生病或疲倦都只是暫時的情況，並不影響我們對這個人的喜好；但試著回想一下，在我們人生經驗當中有沒有那種總是傳遞出病態或倦態的人呢？是不是這些人就比其他人更不容易得到別人的喜愛。 (當然我們要先排除這人的其他條件差異，就只著重臉面的影響) 這其實就支持了我的說法，人的臉面傳遞出這個人的身體狀態，而不同身體狀態所對應的求生或繁衍能力，影響著我們對這樣臉膀的喜愛程度。

人臉非常細緻的不同都能讓我們察覺出這個人的身體狀態，比方在整個人的外表機能還未出現顯著差異的時候，臉上的細紋就能告訴你這人即將告別生育的最佳時間；而男人對女人臉上細紋的嫌惡程度更勝於女人對男人，正好乎應男人比女人更在乎年齡帶來的生育價值。這方面幾乎不需要什麼強有力的證據，因為絕大多數人類的自身感知都能支持這個論點，比方同樣一張臉、同樣的輪廓和五官，人們一定更喜歡皮膚滑嫩的、而排斥有著大皺紋或小細紋的臉；人在臉上所下的掩飾功夫(化妝)比身體其他部位更勤且豐富，而且女人比男人的臉部退化對人的審美知覺更加敏感，這一切都在告訴我們臉部皮膚指示著這個人的生育價值。

除了皮膚狀態以外，臉上的五官輪廓等其他特徵也幾乎全都指向著人的生育價值或生存價值，我們也許不容易對應那美的、帥的部份，但對於那醜的部份總是很容易對應。比方人臉的對稱性表達了這個人是否存在傷殘病徵、或先天上的生理缺陷？你可以自己做個實驗，拿兩個帥哥、或兩個美女的臉，各取左、右兩半邊合成出一張新的臉，然後看看這樣左右不對稱的臉是否仍能讓你感到愉悅？或甚至感到排斥？臉上的其他許多特徵也是如此，例如：眉毛的密度告訴你這個人的眼睛是否會在大量流汗之下被浸溼得睜不開；深邃的眼睛告訴你他的眼睛能被保護的更好，避免被砸向面部的異物擊傷；高聳的鼻樑告訴你他在寒冷的地方能夠更加充份的加熱吸入的空氣；透徹明亮的雙眼和緊實的臉皮告訴你他正處在體能狀態的巔峰；削瘦的面膀反映這個人的營養狀況不佳，可能缺乏生存能力，當然過於充滿衡肉的面膀也同樣告訴了你這人的身體狀態可能不適合承擔高強度工作；還有頭上的頭髮數量和毛岔狀態等等，在在都是反應眼前這個人的身體狀態的指標。

這些臉上的一切特徵都是絕大多數人類直覺當中覺得美或醜的依據，也是我們通常最在乎的自身特徵，同樣是人們極力隱藏或變造的身體特徵。其實臉上的化妝不過就是在做一種生物特徵的欺騙(或者好聽的說法叫修飾)，使我們能夠展現傳遞出來一個訊息：我現在身體狀況極佳、沒有疾病且身體機能巔峰，或者正是最適合懷孕的時候。

美感從何而來？

至此我們能發現，所有的人體之美其實都不過是個體生存和繁衍能裡的指標展現罷了。所謂的審美、眼光、喜好，都只是現代人掩蓋了那羞於觸及啟齒的事物的華麗包裝。即便自詡為高貴文明的人類，在華麗的表面包裝之下也不過都是生物本能展現而已，人類與其他動物並沒有什麼太多的不同，從基因而來驅使我們最在乎的事情，就是生存和繁衍這兩件事；就算再有其他的事情，其實也都是在為生存繁衍這兩件事情服務而已！

那麼美感從何而來呢？為什麼我們認為美的身體總是會和生存繁衍掛勾呢？對此的簡單解答就是：因為只有那些有利於生存和繁衍的本能感覺，才能在漫長的演化歲月裡留存下來；而那些不利於生存或繁衍的本能感覺，會消失在演化的浪潮裡。

不過其實若要追溯到生物的底層反饋邏輯的話，人的美感乃至一切生物的喜好都是無來由且沒有邏輯的，甚至大多數可能具體機制不明，反正就是某些生物特徵能夠開啟對方覺得美的開關，而另外某些生物特徵則會開啟覺得厭惡的開關。其實從正確的角度來說的話，我們其實難以解釋、甚至不能解釋為什麼人的審美是這樣？我們只是確切肯定只有那最正確的審美感覺才能夠流傳延續下來！

如果要更深刻的解釋這件事情，我們需要先來假設一件事：假設人類是從 100 萬年前就砰的這麼一聲出現在世界上。那麼這個時候肯定是什麼人都有，各種奇怪的美感絕對充斥在每個人類個體身上，反而一點都不奇怪了！肯定有人喜歡瘦骨嶙峋的、也有人喜歡肥胖滾圓的；你覺得滿臉皺紋的人讓你敢到厭惡，但肯定有人覺得皮上沒有一點皺折的人讓他倒彈，更有人覺得那擁有反覆皺折的粗糙皮膚能感到興奮愉悅；有人不喜歡站得直挺的，就喜歡痀僂著的樣子；有人不喜歡四肢健全的，就是覺得缺胳膊少腿的性感；有人不喜歡渾身充滿肌肉的，就覺得那骨瘦如柴的讓他砰然心動。如此等等，任何你能夠想像出來的各種奇葩美感，我們都假它確實存在，假設就是會有人覺得這樣子的人美。然後經過了 100 萬年，猜猜看只有什麼樣的「天生的」美感能夠留存下來？

你會發現一件事：如果你喜歡缺胳膊少腿的男性，那麼你的伴侶其實不容易在地球上存活下來；如果你無法接受那沒有殘缺的對象，那麼你將難以產生後代，而你那獨特的審美天性也將難以繼續延續。如果你喜歡年老的女性，那麼你的伴侶將不容易產下後代；如果你無法接受年輕的女性，那麼你這獨特的審美天性也將會消散在漫長的演化歲月裡。而這些，其實就是人類美感的煉製歷史，都是在艱苦的求生路和繁衍的篩選之下精練的最後結果；美感並不是包羅萬象百般接納的，而是有著絕對的對與錯之分，只不過為每個個體的美感進行評分的不是任何一個老師、也不是任何雞湯文，而是達爾文；上百萬年以來，如果人在審美這道題上交出了錯誤的答案，那麼他將會被拋棄在演化的道路上，消失的無影無蹤。

因此那人類的審美，其實並不是我們很剛好的覺得那能夠讓我們生存繁衍的東西美，而是那但凡不能幫助我們生存繁衍的美感，都被篩選淘汰掉了！

審美是否一成不變？

美感與生存繁衍高度連結，存在著對與錯的正確解答，那麼人類的美感是否就是一成不變的呢？答案是既然美感與生存繁衍掛勾，那麼就會隨著不同地區的生存條件而有所差異，例如我們一般都知道的東方與西方對人的美感就呈獻出令人稱奇的不同。此外南方人與北方人、熱帶溫帶與寒帶、潮溼與乾燥等等，在不同生存條件之下孕育出來的人體美感也會產生大大小小的差異，總歸而言其實都是因為不同地方的生存條件不同，最終使得最適合、或最不適合生存繁衍的人體特徵有所差異所致。

甚至於不同時代的不同生存條件也會使得人類的美感發生變化。例如我們常在一些出土的古老洞穴壁畫中發現，古代祖先眼中的大美女往往都是圓滾胖，其實這也是因為在遠古狩獵採集的時代，肥胖的特徵其實表示身上積存了足夠的熱量，比別人更具有忍飢受餓的能力；講到這裡也許有些胖胖的現代人要會心一笑了，是不是覺得如果生在古代就好了？但且慢，請先憋住你的笑聲，因為如果真的穿越回了古代，你真的以為能吃胖是一件很容易的事情嗎？所以某一方面來說，身寬體胖所展現出來的並不只是吃的多而已，還表示你可能是具有權力地位的上層階級，才能在減少勞務的情況下不缺乏食物的供養。總歸而言竟然是因為肥胖的體徵是人擁有更大生存能力的可見指標！

但是隨著人類的生存方式從狩獵採集逐漸步入農業畜牧，糧食的供應漸趨穩定，肥胖的好處漸漸的愈來愈難以體現，反而是它的壞處漸漸使擁有此項特徵的人更趨向於不利生存，因此人類的審美也因此開始悄悄的發生了變化！隨著生存條件的改變，達爾文對於「什麼叫作美」這道題的標準答案一聲不吭的改變了，而且沒有任何人去通知生活著的人們這件事情，人們仍舊一如往常的喜歡這個或討厭那個。來到審判的時候了，當達爾文按牌底下的謎底掀開，他的判決沒有憐憫或寬恕；人們所抱持的從祖父輩傳誦下來的標準正確答案忽然之間就成了極大錯，即便喊冤抱屈，等待他們的宿命依然是被無情的拋棄在演化的道路上，那隨著他們的基因所承載的美感天性也隨之一起消散無蹤；自然之神已經默默開始眷顧那擁有另一種美感傾向的人。這些答題正確的人做對了什麼？他們其實什麼都沒做，只是他們原本非主流的天生喜好正好命中了正確解答而已！這些原本非主流的少數將獲得勝利的果實，他們要發展茁壯，蠶食鯨吞，直到成為人類的主要組成。

那麼回到開始的問題，人類的審美是一成不變的嗎？既對也不對。美感只不過是最佳生存繁衍策略的一個表面現象而已，當生存繁衍的條件發生變化的時候，所謂的審美也就會開始跟著發生變化； 只不過基於基因演化所導致的改變，都是以萬年為單位計算的； 若只考量一兩代人可見的範圍內的話，那麼這就會成為一種無法改變也無法撼動的天性！ 這一項重要的特徵，將是我之後整個兩性相關議題的重要概念基礎。事實上許多現代社會所遭遇的性別相關議題，八九成是因為當代人類社會已經產生了劇烈變化，而那影響我們對事情的任何好惡或所謂「感覺」，卻都是萬年前的基因所給予我們那可能已經不合時宜的天性所致。

結語

這裡我從演化的角度來重新審視並解釋了人體之美感、以及我們審美天性的來源，而我們的審美實際上也極大的影響了我們對於異性的好惡傾向，兩者互相牽扯糾纏。人體的美感可別說是受到生存繁衍的影響了，而根本就是源自於生存繁衍的優勢才影響並篩選了人的審美，然而兩性實際上的吸引和互動關係其實更為複雜得多，並不能只用單一的人體表徵因素來全部解釋。或者換句話說，在這有限的篇幅範圍內只能暫時排除其他一切因素，只單獨討論身體表徵在吸引力上的互相引響關係；至於除此以外的其它部份，只能後續再慢慢探討了。

兩性擇偶的殘酷戰場

Mon, 22 Jan 2024 00:28:27 +0800

前陣子看到了一個節目，這節目主題是在研討在網路兩性交友媒體平臺上，為什麼男性總是很難配對到女性的現象。更加難得可貴的是，這節目使用了很多實際的資料數據來進行分析，以非常可靠的證據和假設來分析這些現象。

這裡我將從這部節目開始，繼續討論兩性在擇偶環境上的一些生態、揭露一些求偶生態殘酷事實背後原因，並且想特別著墨在女性求偶的陷阱上面(畢竟男人的困難相較來說單純明瞭的多)。

那篇節目裡提到了很多的網路交友現象，然而但凡在實際生活中進行過求偶擇偶行為的人，基本都知道這不只是網路交友才有的現象，在現實生活中基本一樣如此。節目裡著重指出了一個普通男性在求偶市場上的各種明顯的困難現象，但稍加思考分析就會發現，這些各種困難其實幾乎都來自於同一個問題，那就是男女在數量上的極度不平衡。 在通常兩性求偶的戰場中，男性追求者的數量一般是數倍於女性被追求者，其他各種問題大多是從此衍生成型的。

但是，有沒有人想過一個奇怪的問題？男性與女性的數量差距真有如此巨大嗎？聯合國公佈的正常標準胎兒男女比例是 1.05，也就是說若有 100 位女嬰誕生，則表示對應誕生的男嬰是 105 位。男女性別比是存在差異沒錯，即便是因為一胎化政策導致全球最高性別比的中國大陸，也不過就是 1.14，而這點差異卻完全無法解釋我們一般所認知的，在求偶戰場上那種男多於女數倍的數量差異！那麼，這些成倍數的男人是打哪來的呢？或者說，那些應該出現的女性都消失去哪裡了呢？

男人的殘酷戰場

男人在戀愛擇偶的戰場中處在極為弱勢的地位大概是當前社會共同認知的現狀(當然這裡只看一般水平的普通男性)，無數男性拼盡全力只為了能找個女伴，並且無數普通男性可能終其一生無法配得、或難以配得任何一位女性。讓男人們必須要在求偶戰場上卯足全力拼殺爭奪的其中一項大的根本原因，就是供需的極端不平衡：追求女性的男性太多，但是被追求的女性太少，後續許許多多的殘酷社會現象其實大多源自於此。而那造成求偶市場上兩性數量極端不平衡的主要原因，我認為有二： 女性的被動傾向、以及男性的超額競爭！

眾所皆知，女人在戀愛和追求的活動當中普遍趨於被動。相對於男性的「追求」，女性傾向於「擇偶」，處於被動的位置等待男性的追求，然後進行挑選。導致這些現象當然有其背後的原因，但為了聚焦討論這次的主題，我不會在此深入探討。所以有些人可以先暫時不用了解男女為什麼會這樣做？我們只先認同現實確實存在這樣的趨向即可。

女性的被動使得在兩性求偶的生態中傾向於被動等待，而非積極主動打開局面。當男人與女人同樣處於單身並且有意交往異性時，男性往往積極主動行動起來，而女性往往不做任何事情，就靠一個「等」。於是我們就看到了為什麼線上交友的男女比例如此懸殊了。即便是在線下的實體聯誼活動，男性的報名人數往往會是女性的數倍，而女性則可能意興闌珊；各種聯誼活動可能一開放報名的當下，男性名額就瞬間爆滿，而女性名額可能直到活動開始的當天都還有剩。這些都是臺灣各路聯誼活動的通常現象。 女性被動的擇偶趨向， 直接導致我們在人口結構上看到的那些本「應該出現的女性」消失在潛在異性的能見範圍外。

當然這不表示女性一定就被動到底不曾主動，只是就市場現實現象來看，女性通常都很能「撐」，大多要直到自己意識到危機感的時候才會有所行動。而這也是為什麼各線下聯誼場合裡，女性普遍年齡偏大的原因；當然，這是另一個故事了，暫且先放著。

說完了消失的女性，我們來看看那超額的男性。那些多出來的男性是從哪裡來的呢？

一個在婚齡階段的普通男人，要面對的是數倍同性競爭者的競爭壓力。對於一個單位的適齡 20 到 30 歲的適婚女性，除了同樣 20 到 30 歲的男性彼此互相競爭之外，還要面對 30 到 40 歲的男性、甚至 40 歲以上男性的激烈爭奪競賽。因為女性被動的關係前面可以追求的女性數量已經吃緊了，後面卻還有更多虎視眈眈的競爭者們緊吃，這才是導致為什麼男性數量總是數倍於女的根本原因！於是男性追求者激烈競爭互相殺伐，而女性則能以逸待勞，可以坐高姿態提條件要求。這就是男人的困難，也是男人天生就要拼個你死我活的宿命！

女人的殘酷現實

既然兩性求偶的天秤是如此不平衡，那麼女人在擇偶這件事情上，不是應該極其愜意自然、好整以遐的嗎？又怎麼會有困難和殘酷呢？其實粗淺來看，女性在擇偶生態上存在著兩個比較明顯的誤區。

歲月殺豬刀

女性的首要最大敵人就是自己的年齡！ 其實在前面對於男性艱苦困境的敘述中就已經隱隱表達出了這個殘酷事實，為什麼男性會超額競爭呢？！為什麼那 30 多歲的男性放著同樣 30 多歲的女性不追？為什麼那 40 多歲的男性放著同樣 40 多歲的女性不管？為什麼男人們一股腦爭破頭，全擠去追求那 20 多歲的女性了？許多女性沒有意識到受到男性的群起追捧呵護的背後是源自於自身的年齡優勢，而以為是她自己的魅力、樣貌、品味、或是能力吸引到眾人的愛戴，或者就是低估了年齡的殺傷力；直到一天那大限之日突然到來時，才赫然發現那些追求者不知何時早已遠去，不再受到歡迎，甚至再不太有人願意搭理，然而那個時候卻已經後悔莫及了！

屬於女性的精華歲月就是從成年後開始直到大約 30 歲之前，青春花期就是這麼短短的十年，並且過了就無法回頭。這裡我們不扯什麼性別平等，因為兩性的吸引力就是來自那原始的吸引力。我知道有些女性很反感男人看年紀這事，但是現實就是一兩個人聲嘶力竭的叫喊是不可能攔得住一整群人的審美眼光；不管如何鼓吹性別平等意識，也無法讓那些原來不對你感興趣的男人突然就喜歡上你，最後你還是得屈服於現實。

一旦過了青春的最佳年紀，自身價值就會快速的往下掉，殺個你措手不及！在這個問題上，那些基於兩性公平尊重平等價值觀衍生的說法並非不對，事實上還頗有一番道理；只是抵抗不了人性天生的審美。這就是明幌幌的現實，是男性群體源自於天性上的偏好，再多雞湯文也無法扭轉他人的喜好！ 一群女人們受到集中寵愛的另一面，就是另一群女人被無情拋棄； 男人們對年輕女性怎麼樣的愛戀執著，對芳齡已過的女性就是怎麼樣的嫌棄排斥； 男人們這一邊怎麼樣的瘋狂相爭，另一邊就是怎麼樣的無情忽視。

雖然年齡的威力看似已夠讓女人苦惱，然而那自身的人性卻可能讓女性更加雪上加霜。理想務實理性的情況下，我們對外在的要求應該匹配自身的現實條件，例如你知道自己是個學渣，當看見隔壁家的兒子因為上不了臺大而懊惱的時候，你知道對於自己來說只要能考上任何一間公立大學就滿足了，甚至有些人可能認為只要能夠考上任何一間大學就滿足了。然而對於屆齡的女性，正所謂由儉入奢易而由奢返儉難，曾經的她可是擁有那樣的高價、受到那樣的追捧，曾經連怎麼樣怎麼樣的人都被她給拒絕了，現在叫她要真實面對自己，找個與當下自己匹配的就好了，這談何容易呢？ 這時候人性那不甘心、不甘願、不願認輸、不願妥協、不願承認失敗的部份不容易壓制， 而這將驅使女性容易因此錯過一個又一個的最後機會。 有些女人經此之後會開始劍走偏峰搞極端，內心反感並且大力抨擊那些會挑剔女人年齡的男人(基本上幾乎就是所有的男人)；對於這些女人，我只能送給她一句話：「你知道什麼叫狗吠火車、螳臂擋車嗎？」

在我經歷過的每一場成人聯誼的現場(學生聯誼不算)，幾乎就是一群大齡女性以及另一群意興闌珊的男性們，互相表演看似給足面子的一場戲，但是絕大多數時候可能是誰也看不上誰。男人們在現場當然不會把心底真實的想法說出來，只是對更進一步的行為可能沒有太大的興致而已，看在女性的眼裡大概會認為這些男人們木訥、內向、不懂互動；但是錯了，這只是表面現象而已，如果現場出現了個真正的年輕小姐的時候，你可能才會赫然發現原來這些男人是這麼的積極主動、開朗又活潑，甚至風趣加幽默！

那少數的優秀

求偶戰場上除了男女數量不平均所引發的一連串現象之外，本文引用的那節目裡還提到了另一個非常重要的現象： 兩性的吸引不是平均的，人們會更傾心於更優秀的異性，換句話說那更優秀的人搜刮了大半異性的愛戀。 這部份還算好理解，人嘛誰不是更喜歡那更好的呢？但是除此之外卻還有另外一向更關鍵的現象： 比起男性，女性普遍更加傾心於那更加少數得多的極少數優秀男性！ 我們不討論這特性是怎麼形成的？但是這項觀察事實卻是在除了年齡之外，給女性的擇偶戰場真正加上殘酷競爭的糖衣砲彈！

女性更加集中愛慕那更加少數的優秀男性精英，用白話文來舉例那就是：如果說男性普遍喜歡並追求那只佔了 25% 以下的漂亮女人，那麼女性就是普遍愛慕追逐那只佔了 5% 以下的精英男人。前面我們知道原本男女數量就已經非常不平衡了，再加上這項兩性之間的偏好差異，進一步加劇了我們先前已知的情況，於是：女性會更傾向於看不上客觀條件其實與自己同等級的男性，甚至對於稍優於自己的男性都容易「沒感覺」；而大量普通男性無法、或難以覓得一個匹配的女性，即便是稍加優於平均水準的男性在擇偶一事上依然能感到吃力。然而這些都只是在一般人範圍裡發生的現象，但若我們將目光聚焦在排名最前面的那些優秀的人身上，整個情況就會完全大翻轉！ 在拔高擇偶的戰場之中，女性面臨的競爭壓力非常激烈，能夠成功達陣的僅是少數； 而那些位在尖端的優秀男性才是真正的大贏家，握有完全的選擇權和話事權！ 在尖端頭部的人群中，那前端 2% 的女性也許能夠吸引 40% 男性的青睞，但是前端 2% 的男性卻可能擁有 80% 女性的選擇權。對於一個前端 1% 的女性來說可能並不存在什麼問題；而那真正的問題，也是這個段落的重點，其實是發生在比方前端 10% 的女性想要搶奪前端 1% 男性的時候！

只要稍加不留意、只要稍加不清醒，上述的現象就容易讓女性掉入一個認知陷阱中， 未意識到其實在競爭激烈的競賽中並未具有足夠的價值，反而自我感覺以為擁有擇偶優勢。 而這才是此項生態特性真正具有殺傷力的地方！對於普通男性來說，實際的擇偶競爭激烈，並且男性一般也都能認知到這項事實；對於特別優異的男性來說，他們認知自己擁有絕對擇偶優勢，可是他們實際上也是真的具有擇偶優勢；但是同樣的事情放在女性身上(比如前 15% 的女性)卻很容易產生認知落差，客觀事實之下她們的確在 85% 的男性中擁有選擇優勢，但是若論及嚮往仰慕的那 5%，卻其實是處於劣勢中。

我們偶爾能從某些網路或媒體管道看到一些誇張的擇偶條件案例，例如一個女人相貌平平、也看不出具有什麼真正突出驚豔的特殊優秀素質，卻能開列出一長串嚴苛的擇偶標準？這些案例裡面可能只有極其少數是真的精神有問題或故意為之，而絕大部份其實是陷入了比較嚴重的認知誤差陷阱裡。她們很可能並不覺得這些篩選條件有什麼不合理之處，並且完全覺得自己配得上。這些女性其實並非完全沒有優秀之處，恰恰相反，她們在一般水平的戀愛市場裡多半具有一定的優勢條件，例如長相比一般人更漂亮、身材比一般人更加姣好等等，因此在她們身邊通常並不缺少追求者和愛慕者。雖然她們可能看不上圍繞在身邊的這群男性，可是在眾多男性的吹捧簇擁和上趕著的討好中，她們認知到自己在戀愛市場中位處優勢高地。這份對自己身價的自信，使她們信心滿滿的向著自己內心所嚮往的那群傑出精英男性的世界進發，一腳踏入那個自以為游刃有餘實則慘烈困難的殘酷戰場。於是她們擺出了高姿態，可能是真心覺得自己真的有本事配得這樣的男性，也可能是為了設下門檻來篩除那原本就已經過多的追求者，終於洋洋灑灑邏列出了那些讓我們嘆為觀止的嚴苛條件。然後，在這個完全匹配不上的戰場，她們被叮的滿頭包，敗的一遢糊塗。

條件匹配錯位所導致的荒唐並不是只有嚴苛門檻條件這一種，只是這種型態比較容易擺上討論關注焦點而已。其它還有例如有些女性面對比自己高了好幾個等級的優秀男性時，會要求對方對自己如舔狗般呵護備至、容忍自己的小作大鬧，必須要這樣對自己好、應該要那樣對自己安排周到，要捧在手掌心時時服侍到位等等。作為一個屬於少數特優秀的男人，先不論他是否能夠經常抽出這樣的時間和精神來應付這位女性，單單就論一個真正具有絕對優勢地位和選擇權力的男人(其實女人也是)，誰能長期忍受得了這樣的伴侶呢？於是這些人當然只能落得最後大敗而歸的下場。她們的盲點就在於仗著身處在一般環境中所擁有的高姿態資本，卻拿去應對高端範圍的男人；在普通環境下受到的高價值待遇給了她對自身定位的錯誤判斷，卻未意識到在高端環境下其實並未擁有什麼真正拿得出手的資本。

還有一些其他型態的認知誤區其實也屬於這類陷阱的範疇，例如這幾年在中國大陸常能聽見的說辭：「全中國適婚單身人口，男人比女人多了三千萬，我作為女人怎麼怕嫁不出去？我大可以好好挑一挑撿一撿！」這話說的其實真是事實，問題是你以為那多出來的三千萬男性真的處在你能接受並選擇的範圍內嗎？這些大量「多出來的」男性都在各處偏遠鄉下，經濟水準也大多都在全中國最末地帶，當然如果你願意接受的話，那也是真的不怕嫁不掉，也真的可以好好挑一挑；問題是，你願意嗎？但是若回到了那些你所願意接受的範圍內的男性，可先別說排名前還是後了，在許多發達大城市裡，單身男性的數量甚至還不夠女性瓜分的呢！於是許多女性就在自以為可以安坐高位等待良緣的錯覺下，輕易的錯過了一切機會，等到自身優勢逐漸消耗殆盡時才赫然發現事情的真像，然而一切都已經難以挽回了！

如果你要我用一句話來總結描述這一個陷阱困境，那就是： 未意識到身處在一處激烈競爭與淘汰的擇偶戰場； 受到在某另一個擇偶生態的優勢待遇蒙騙，錯誤的以為在嚮往的目標生態裡也具有同等的優勢； 在內心嚮往的生態裡其實並沒有真正拿得出手的資本，但是對於那能讓自己真正具有實際優勢的那群人群，卻又並不在自己能夠接受的選擇範圍內。

總結

這篇文章粗淺的論及了兩性在擇偶一事上面對的困難和陷阱，但是有鑑於人們通常對某部份主題會比較敏感易受傷的心態參染，可能會產生一種我在批評抨擊女性的感覺，因此我得先為自己做個簡單的澄清。這篇文章的主題就是在論述困難和陷阱，因此才整篇都在論述各種困難和陷阱。這裡我從未、也不會述說女性必定會落入什麼樣的圈套、或一定會有什麼樣的悲慘結局，甚至在實際生活圈裡，也許那認得清狀況、沒有淪落到我所描述的遭遇境地的才是大多數；但是本文所提出的這些憂慮並非沒有根據。陷阱擺在那裡恰巧沒有人踩到，並不表示那個地方不危險，不值得提醒路過者注意。而且相信本文的讀者若已達或超越婚戀年齡，可能也早已經發現在自己的朋友圈裡面或許就存在不少中招者。

總歸而言，男性和女性遭遇的問題樣式不太一樣。男性的困難往往很容易理解，簡單又純粹，而這也是為什麼我較少著墨男性困難的主要原因。相比於男性，女性在擇偶生態中往往是更加輕鬆容易的(請和差不多同個條件水準的異性比較)；不像男性的困難是那樣明晃晃而又絕望於突破，那阻礙女性擇偶的因素往往是以陷阱的困境而存在，讓女性在客觀具有擇偶條件甚至具有優勢的情況下，默默被坑害；而也是因為同樣的原因，才讓社會上議論剩女的熱度遠高過於討論剩男的熱度。

都說男追女隔層山、女追男隔層紗。撇除掉部份極端因素，在絕大部份符合正常通常的兩性環境中，女性往往稍微積極主動一點，給男性個橄欖枝，幾乎就能立刻收穫一個差不多相稱的男伴；而這可是多少男人夢寐以求的簡單版求偶遊戲呢？ 在現實生活中的絕大多數時候，一個女性就是比同等對標的男性更加容易脫單，而且容易得多。 更何況就算年輕女性什麼都不做，通常也會有一群男性主動圍繞著她！ 年輕男性的困擾往往在於如何獲得一位女性的芳心，而年輕女性的困擾往往在於如何應付蒼蠅般男性的襲擾！ 但是就是這樣一個簡單模式的遊戲，卻偶爾能看到女性將手上一副好排打了個稀巴爛！於是我常感慨萬千，如果世界有一個主宰的話，那麼不知道祂到底是不是存心故意戲弄著女性？ 相對於男性的困難艱苦是如此簡潔明瞭，女性的陷阱和困境卻往往不那麼容易被察覺。 那就像是藏在花叢中的陷阱、是那藏在蜜糖中的毒藥；如果說那些陣亡了的男性是在明幌幌的廝殺戰場上身中數刀壯烈犧牲，那麼這些中招的女性往往就是在漂亮的花園和華美的氣氛中陷入泥濘，甚至即便終於發現原來在美麗花團之下竟然是捕獸夾，也常常不願意主動掙脫反而一腳踏進去，甚至幻想捕獸夾會自動變成簇擁的棉花！

以色列巴勒斯坦又戰了，這次打的兇啊！

Thu, 02 Nov 2023 00:20:28 +0800

最近以色列和巴勒斯坦又打在一起了，激烈程度為五十年來所未見，各種慘烈的情況都給世界帶來了廣泛的關注和討論。相關的各種論述已經很多，不論是站在以色列派的、還是站在巴勒斯坦派的，實在不需要我再多說什麼。戰地打的火熱的同時，世界其他地方也充滿了各種爭吵與抗爭、仇視與報復。為此，我只是突然想起了聖經上面的一部份章節，算是作為我個人對這個事件的回應吧。

對外僑，不要苛待和壓迫，因為你們在埃及也曾僑居過。對任何寡婦和孤兒，不可苛待；若是苛待了一個，他若向我呼求，我必聽他的呼求，必要發怒，用刀殺死你們：這樣，你們的妻子也要成為寡婦，你們的兒子也要成為孤兒。

– 出谷紀，第 22 章，20-23 節

我要為我的愛友謳唱一首論及他葡萄園的愛歌：我的愛友有一座葡萄園，位於肥沃的山崗上；他翻掘了土地，除去了石塊，栽上了精選的葡萄樹，園中築了一座守望台，又鑿了一個榨酒池：原希望它結好葡萄，它反倒結了野葡萄。耶路撒冷的居民和猶大人啊！現在請你們在我與我葡萄園之間，判別是非：我為我的葡萄園所能做的，還有什麼沒有做到？我原希望它結好葡萄，為什麼卻結了野葡萄？現在我要告訴你們，我將怎樣對待我的葡萄園：我必撤去它的籬笆，讓它被吞噬；拆毀它的圍牆，讓它受踐踏；我要使他變成荒地，不再修剪，不再耕鋤，荊棘和蒺藜將叢叢而生；並且我要命令雲彩不再在它上降下時雨。萬軍上主的葡萄園就是以色列家，而猶大人即是他鍾愛的幼苗。他原希望正義，看，竟是流血；他原希望公平，看，卻是冤聲！禍哉，你們這些使房屋毗連房屋，田地接連田地，而只讓你們自己單獨住在那地域內的人！萬軍的上主在我耳邊宣誓說：那許多房屋必將成為廢墟；巍峨華麗的，必無人居住。

– 依撒意亞，第 5 章，1-9 節

男女真的不一樣 - 淺聊性別天性

Thu, 13 Apr 2023 01:35:00 +0800

最近上門拜訪親戚，見了一個還沒上學的小女孩在玩辦家家酒、逗弄她的玩偶們。她的母親在旁邊說，這小女兒每天早上起來就是要把自己打扮的漂漂亮亮的，把五顏六色的塑膠珠寶掛滿全身，我突然有感而發，「這一切全都是天性啊」！

在我們小的時候，正是國家社會開始強調性別平等、正在開始試圖打破傳統性別框架的時候，我們從小受到的教育自然也是兩性平等，許多話語我至今仍能記得，比方說「男人能做的憑什麼女人不能做？」「男孩女孩一樣好！」「男生為什麼不能哭？」「男生也可以玩洋娃娃、女生也可以玩汽車！」等等等等。到了年紀漸長，性平意識逐漸成為社會主流思想，凡傳統觀念裡面對於男與女(其實主要是對女) 的各種壓迫限制和各種思想觀念，都會被視為腐朽陳痾，急欲除之而後快，這其中包括了職場關係、親屬家庭、和子女教養方面等等。

然而當我真正進入社會，實際了解到許許多多的現實與實務邏輯之後，才曉得遠來以前被教育了大量錯誤(或者叫作「與現實不符」)的觀念，也才明白原來很多傳統的性別觀念有其演變脈絡和存在的價值。關於這些部份，那是好多好多的心得感想，以後再慢慢一件一件說明；而在這篇文章，我只想要簡單的在性別的天性上，去做些簡單解釋的解釋與反駁而已。

在小時候受教的觀念中，男孩與女孩的差異僅僅只有生理構造不同而已，而所有其他的部份都是平等的，這包含了所有除了生理差異以外的所有其他部份。但是我們知道在現實中，男孩與女孩在性格上、習慣上、情緒上、和思想上都存在大大小小的差異，而在性平教育中，這些差異都被歸咎於是後天的教養差異所造成的。這怎麼說呢？就是當我們生了一個男孩，自然會給他購買在我們作為父母的思想觀念中，覺得應該屬於男孩子的玩具，比方汽車、飛機、積木、槍械等等，除了有形的器物之外，我們也會懷著讓他成為我們想像中應該要成為的男人形象來教育他，比方男生要勇敢、要大氣、男生不可以哭……等等；如果是女孩子的話，那麼父母就會給他屬於女孩子的玩具、以及期待她成為女孩的教養觀念，如此一來，男孩女孩長大之後自然而然就會變成傳統所期望的，男人的樣子、以及女人的樣子。這種性別無差異觀念認為所有性別的思想、習慣、和性格差異都來自於後天的教育，並且相信如果將男孩和女孩放在一個獨立的完美無差別環境下教育成長，就會得到真正自然分佈的人物性格。

然而經過幾十年的生活觀察，可以斷定以上理論是錯的。孩子的確在不同的教養方式之下會導引出具有差異的人格特質，然而在原始性別中，那些刻在骨子裡的特性卻可能佔據男女差異上更具主導性的地位，並且有許多明顯能夠觀察的事實結果可以支持這些基於性別差異所導致的，從天性上就存在巨大差異的論點。比如說，男生們的理工科目表現通常比女生們更加傑出，而女生們的文史科目表現普遍比男生們傑出；如果你要說那是因為抱有傳統過時觀念的大人們本來就認為男孩應該要擅理工、而女孩應該要擅文史，那麼你要怎麼解釋男生的數學、特別是在空間結構上的數學理解與計算普遍強過女生？我想應該沒有哪個大人覺得女生數學不應該傑出了吧？要怎麼解釋為什麼別人實驗出來，幾個月大的男嬰就能對機械結構玩具產生反應？怎麼解釋男孩子普遍對槍砲武器感到強烈興趣、而女孩子卻普遍不感興趣？我想不管男孩還是女孩，現代的家長應該普遍都不太樂見孩子喜歡打打殺殺玩槍弄刀，更別提還要刻意培養，然而男孩子卻通常更有暴力傾向、喜好武器和打殺。

我拜訪的那位母親她說，她們也買汽車玩具、也買積木玩具、還買電子與科學等等玩具，但不管任何玩具，到她女兒手裡總能把它玩成辦家家酒，為此她們也很是無奈。其實仔細觀察便不難發現，孩童時期或甚至嬰兒時期的女孩子，就是會對繽紛的色彩感到興趣、就是比男孩子更早會說話、並更早能夠掌握語言。這些是天性，天性就是你不刻意引導也會自然發展出來的，甚至連你刻意引導還不見得能夠有效扭轉的；而男孩女孩的原始天性才是主宰了男人與女人各種思想性格差異的根本原因。

除了上述明顯可以在統計分析裡面看到的事實以外，還有更多不是那麼明顯的性別差異表現，比如說不管在傳統社會還是現代自由社會，對性和色的教育都是偏向迴避和壓抑，可是男孩子卻本能的更會想性騷擾異性。另一方面，現代成年女性不管多麼熱衷個人事業的打拼，在她們幼年孩童時代時卻通常會更明顯直白的表現出想要繁殖後代並仔細養育的母性，傳達出對隱身家庭做為人母的本能需求；相比於此，某些比例成年女人表現出來與男人無異的事業心以及對隱身家庭的鄙視，反而更像是後天環境培養所導致。

關於這些差異的更詳細的故事，我打算以後再慢慢討論，這次並沒有過多的去深入解釋和辯證，只是作為一個引子，作為系列文章的起頭，也是在提醒所有那些想要探討性別平等的人，或甚至只是抱怨遭受性別壓迫歧視的人： 男性與女性的天性差異確實是存在的，並且甚至絕大部份男女之間的思想行為差異都源自於此！ 在生活中也不要忘記： 思想是可以推翻的、文化是可以改變的，但是那源自骨子裡的天性沒有個五千上萬年大概是動不了了！ 那些由於本能天性所導致的行為思想傾向也好、身體極限也好，由它們所帶來的各種差異結果是自然且符合科學和邏輯的，無法奢望透過人為的價值觀來大規模導正到理想狀態！

社會歧視大齡剩女嗎？

Wed, 29 Mar 2023 00:07:24 +0800

在網路上看到不少關於大齡剩女的討論，各有內容，但不論討論的內容為何，對於社會上的人們會熱衷討論這件事情的這個現象，也引起了不少女性的抨擊。許多女性大力批評人們邪惡的嘴臉、以及哀怨這個社會對大齡剩女的不友善，就是對於流傳的「大齡剩女」這個詞都充滿了對女性的種種歧視，為什麼女人必須得結婚才是圓滿等等云云，處處充滿了對這整個社會現象的反擊情緒。

而我對這些女性們的反擊言論，則是輕蔑一笑！

為了避免有些人不知曉「大齡剩女」是什麼？這裡簡單說明：
大齡剩女為網路流通用語，意指年紀已過一般婚育年齡、或已逼近一般婚嫁年齡上限， 卻仍未進入婚姻狀態、甚至沒有異性伴侶的女性。 大齡剩女一般認為帶有貶意，其「剩」一字即指在婚戀市場中被淘汰剩下之意。 (當然我並無意刻意歧視或詆毀女性，僅僅只是解譯已經存在的現象及相關用語)

我們先來看看一段簡短的對話：

一位女士問大師：大師、大師，為什麼愈美麗漂亮的女人總是愈情路坎坷呢？
大師：為什麼美女情路坎坷？那是因為沒有人在意醜女她情路坎坷不坎坷！

這是一段簡短的網路笑話，卻道盡了為什麼大齡剩女會成為討論話題的核心。社會難道真的是對大齡的剩女充滿歧視、偏見、與敵意嗎？的確女人大齡未嫁容易引起義論，可是社會上也存在著可能更多的大齡未婚的男性啊！怎麼就沒人討論他們了呢？這就是一件令人扎心的事情了，事實上女人之所以會被討論、會被關注、會被議論，以某種意義來說，那是因為人們還願意在乎她們，至於男人呢？沒有人想去管他們死活！與剩女們相對的是數量可能相當的剩男們，默默隱身在社會每個角落，沒有人關心、沒有人在乎、也沒有人談論。

上面的說法雖然符合現狀，但也過於表面。為什麼人們更樂意關注女人為什麼未婚呢？原來是因為女人才能提得起人們的興致啊！怎麼說呢？舉個例子，「阿里」中學畢業的學生去念了「不達」大學，這件事能夠提起你的進一步了解的興致嗎？但是當今天傳出「建國」中學的畢業生去了「不達」大學，是不是興致就來了呢？或者是換成「阿里」中學畢業生考上「臺灣」大學，我想都可以成功的吸引人們的眼球關注，原因就在於這件事情與我們既有的認知產生衝突，使我們提起興趣，而建國上臺大和阿里上不達則是再稀鬆平常不過的事情，所以沒有人在乎。

觀察閱聽許多大齡男女之所以未婚無伴的故事就會發現，男人單身的原因千篇一律，完全合乎預期，全然沒有想要深入了解的動力；而女人單身的原因則有各種花樣，她們的故事能夠不斷的激起人們的興趣，因為這些事蹟總是能夠不斷的衝擊你的情緒、刺激你的感官、一再刷新你的認知、突破你的界線，使得人們一聽聞大齡剩女的事蹟就精神抖擻，並且樂於奔相走告！

在 Windows 上架設 SSH 服務(使用 Git Bash)

Thu, 23 Feb 2023 19:58:46 +0800

網路上隨便就可以搜尋到「如何從 Windows 使用 SSH 連線 Linux 主機」、以及「如何架設 Linux SSH 服務」等主題，但反過來討論「如何使用 SSH 連線 Windows 主機」的話題就很少了，而這這也是我寫這篇文章的主要原因，於是這裡要來教你如何在 Windows 上架設 SSH 服務。

為什麼要在 Windows 上架設 SSH 服務？

我自己有研發跨平臺應用的需求，需要隨時測試一些東西在 Windows 上的執行效果，或是執行一些必須在 Windows 上面執行的處理工作，無論這臺 Windows 到底是實體機器還是虛擬機器，頻繁的切換不同操作環境都讓人有所煩躁，才會這麼殷殷期盼一個能夠使用 SSH 連線並直接操作的作業環境。

一般來說在 Windows 上面架設 SSH 服務的資料比較少，因為以往有這樣需求的群眾少。 SSH 原先是流行在 UNIX like 環境下的遠端連線機制，由於伺服器領域是 Linux 佔大宗而終端桌面是 Windows 佔大宗，因此詢問如何從 Windows 透過 SSH 連線至 Linux 的詢問與解答自然多；反之從 Linux 終端連線 Windows 伺服器的需求便非常低，況且通常會熟悉並選用 Windows 作為伺服器系統的人，通常更習慣使用 RDP 遠端桌面連線登入操作；最終大概只有像我這樣平常使用 Linux，因故需要連線登入 Windows 機器的人，才會對這種連線方案感到興趣。好在近年因為微軟推出的 Bash on Ubuntu on Windows 軟體方案 (後來變成 Windows Subsystem for Linux (WSL))，拉攏了一票原本的 Windows 使用者有機會去習慣和適應 Bash 的操作體驗，這才讓更多的人有了想要在遠端登入的情況下在 Windows 上面繼續延續 Bash 體驗的想法吧！

在 Windows 上架設 SSH 服務的幾個主流方案

在有了使用的動機之後，蒐集網上現有的對於 Windows 架設 SSH 服務的方法的方案，整理得到了主要流傳的三種方案如下：

使用 Windows 10 內捆綁的 SSH 服務
安裝使用 OpenSSH
安裝使用 Git

安裝 OpenSSH 是最原汁原味的方案，也是早先時候的唯一選擇；缺點就是這方案之下真的就只有單純的 SSH 而已，我想因該沒有人單純只是想要體驗 SSH 連線的感覺！所以安裝了 OpenSSH 之後，可能還要移植很多自己需要的一眾相關程式工具。

從 Windows 10 的 1809 版開始，內建捆綁了 SSH 功能，成為當前的主流方案，可能是因為這個系統內建的服務和 WSL 環境最原生協作順暢的緣故；缺點就是這個服務預設並沒有啟用、也沒有安裝，要去啟動這個服務還需要一些神奇又繁瑣的操作，並且只能在 Windows 10 以上才能夠實現，對於我這種還在使用 Windows 7 或甚至 Windows XP 的人而言更是無緣。

最終對我而言最佳的便是第三個方案，使用 Git for Windows。當然哪一個方案最好這件事很可能需要審視您自己的應用場景，對我最適用的東西不見得對你也是，因此我只是列出了我為什麼選用 Git 方案的考量，好讓你可以快速判斷你的需求與我的想法是否相合？

我之所以最終選擇使用 Git 方案，其相對其它方案的一些優點如下：

我本來就有在使用 Git，所以對其並不陌生，甚至有得時候即便我不需要 SSH，也是需要 Git 的。
Windows 版的 Git 安裝簡便，更重要的是它還夾帶了 Bash 環境，讓我不需要另外安裝移植什麼東西就能擁有一個功能豐富的 Bash 使用體驗。
除了 Bash 本身之外，還包裹了一眾在 Linux 下常用的基本工具程式。這使得我不只擁有 Bash 環境，還可以延續許多在 Linux 上的使用習慣、工具、和腳本等等，也不用改寫 BAT 腳本，大多情況下可以直接通用一個 Shell Script 腳本。
Git 可以安裝執行在 Windows 7 和 Windows XP 系統上。

也因為上述這些原因，一直以來在 Windows 上我都把 Git 當成 Bash 來使用，即便沒有要在上面做軟體開發工作，也會安裝 Git 來用。因此為我來說，使用 Git 方案省事方便，不用再安裝其他東西，還能和原來的使用環境整合在一起，是所有方法裡面最優良的方案。

安裝與配置

首先下載安裝 Git for Windows。

其中若您的系統是 Windows XP 的話， v2.10.0 是最後一個支援 Windows XP 的版本。
安裝完成後，電腦上就會出現 Git Bash 程式(在開始程式集裡)。對其點擊右鍵，點選「內容」，在「相容性」頁面下勾選「以系統管理員的身份執行此程式」。
執行 Git Bash 程式(以系統管理員身份)。以下各步驟除有特別說明之外，都是在此環境下執行的。
產生服務器金鑰：
```
 ssh-keygen -A
```
編輯 SSH 設定檔 /etc/ssh/sshd_config：

SSH 設定檔的內容請按自己的需求修改，絕大部份和 Linux 上的 SSH 設置沒有不同，但提醒若不打算將公鑰放在 Windows 上面的話，就要啟用密碼登錄功能(PasswordAuthentication yes)。
若要使用密碼登入的話，就要記得要設定登入密碼，特別是在很多人可能並沒有設定 Windows 登入密碼的情況下：
```
 passwd [user]
```
不過如果使用公鑰登入的話，就可以跳過這個步驟。
執行 SSHD 程式以啟動 SSH 服務：
```
 /usr/bin/sshd
```
這個程式可以很放心的依據自己需求重複執行多次而不用擔心，因為 SSHD 可以被重複執行而不會產生衝突情況，它有自己的內部管理機制，確保只有一個執行中的實體。

不過由於缺乏服務管理機制，中途要停用服務程式的話，就只能使用 kill 家族程式來停止了！
設定開機自動執行。

在完成第一次的設定後，之後每次啟動 SSH 服務時只要再執行一次 /usr/bin/sshd 即可，但我想為了人的懶惰，我們可能更希望能夠在系統開機的時候自動啟動這個程式。

為了開機自動啟動 SSH 服務，請在 /c/Users/<username>/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/ 下新增一個名為 sshd.bat 的文字檔案，並填寫內容為：
```
 "C:\Program Files\Git\bin\bash" -c /usr/bin/sshd
```

常見問題

提示權限不足而無法建立檔案：

請使用系統管理員權限執行 Git Bash 程式來進行操作。
錯誤訊息 “sshd re-exec requires execution with an absolute path”：

請使用絕對路徑執行 sshd 程式，通常是 /usr/bin/sshd。
錯誤訊息 “Privilege separation user sshd does not exist”：
1. 建立 /etc/passwd 文件並填寫內容：
  
  sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
2. 建立 /var/empty/sshd 資料匣。

Reference

自製貪吃蛇遊戲

Mon, 24 May 2021 21:40:00 +0800

最近完工了一個計劃已久的遊戲：貪吃蛇。要說這東西有什麼實際用處？其實就是滿足個人愛玩的心態，做個遊戲來玩。當然，別人玩的是遊戲的內容，而我玩的則是開發的過程。

這個貪吃蛇與經典的貪吃蛇老遊戲基本沒什麼不同，不過既然是新開發，只是復刻老遊戲顯然不能滿足我的願望，於是我在重製老遊戲的同時，還加入了一些個人的設計。

這個遊戲的最大特點就是：它是多人連線版的貪吃蛇，也是這遊戲的最大樂趣之所在。它最多可以支援八個人一起遊戲，讓八位朋友可以互相競爭、互相廝殺！

本來還想說這個東西應該不是什麼困難的程式，結果一做下去，就從去年(2020)二月做到現在(2021-05)，足足花了一年多，編寫超過一萬兩千行的 C++ 程式碼，實在是……常常腦子想的和實際發生的不一樣啊！

遊戲使用說明

把遊戲下載下來解開後會看到，整個遊戲程式只有三個檔案：

snakes: 是主要的用戶端程式，一般執行這個就可以了；
snakesd: 另一個帶 ’d’ 結尾的 snakesd 是伺服器程式，主持遊戲時用的，一般放著不管就好；
example-scene.snksc: 最後一個結尾是 .snksc 的是遊戲場景檔案，它本身是個純文字檔，包含了範例和說明，如果想要自製遊戲場景的話可以參考使用。

當遊戲程式一執行起來，首先會看到的是上面這個主選單畫面。這個遊戲是以終端機為操作介面，之後的其他操作畫面風格大約都是長這個樣子，值得注意的是畫面最下面有一行反白的部份，它會顯示一些重要的操作提示，當你在任何時候不知道應該要怎麼按的時候，就要記得往下面看一下，通常就會有一些解答提示。

回到主選單，這裡有兩個重要的功能：Join Game 和 Create Game。其中 Join Game 就是搜尋並加入網路上其他人開的同一個遊戲，而 Create Game 自然就是讓你自己開一個遊戲給別人加入。然而就算找不到朋友一起，還是能玩遊戲的。雖然遊戲設計是以多人連線為基礎，但也支援只有一個人連線玩遊戲的情況。

若進入 Join Game 選單，就會顯示上面的頁面，程式會自動搜尋並顯示同一個區域網路有沒有人開了遊戲，然後就可以使用上下鍵選擇，並按下 Entre 來加入某個遊戲。其中要注意的是遊戲列表中的 Status 欄位，只有顯示為 Joinable 的場次才能夠加入，正在進行遊戲的場次是不接受新玩家加入的！

除了區域網路之外，程式也支援網際網路的連線，按下 Ctrl+A 就可以手動輸入連線 IP 或網址。只是網際網路的連線和伺服器架設部份，因為牽涉到一些一般人可能比較不熟悉的網路專業，所以這個功能比較不常用就是了。這個功能對於懂的只要這樣提點就會用了，而對於不懂的也很難三言兩語解釋明白，結論就是一般人通常還是推薦使用區域網路連線就好了！

當成功的加入了某個遊戲後就會顯示上面這樣的畫面。這時候遊戲還尚未正式開始，基本就只能聊天而已，只要按下 Ctrl+T，即可輸入文字訊息，然後按下 Entre 送出訊息，送出去的訊息就可以被所有的玩家看到。只是這個訊息功能並不支援中文文字，只能夠使用英文！

另外注意很重要的一件事：在這個畫面裡，若沒有其他考量的話， 請儘快按下 Ctrl+G 按鈕，只有當全部的人都這麼做以後，遊戲才會真正啟動。

在整個遊戲進行的過程中，除了聊天功能以外，基本上只能使用鍵盤方向鍵來改變自己所控制的那條蛇的行進方向。如果花花綠綠的畫面讓你搞不清楚誰是誰的話，只要記清楚一個最重要的事情就好： 鮮綠的那條蛇一定就是你！ 遊戲程式的設計是這個樣子的，每個玩家都有一個顯示的顏色，但不管玩家到底是什麼顏色，自己看自己永遠都是鮮綠色的。

如果你問我說你的終端機不支援顏色顯示的話怎麼辦？這個……那個……我也不知道，就自己看著辦吧！終端機的表現能力就是這樣而已，已非我的能力所能彌補。

此外，遊戲畫面右上角會顯示每一位玩家的積分和排名，對遊戲本身沒什麼影響，就是作為一個參考資訊的存在，讓玩家們有互相較勁的依據而已。

當場上僅剩最後一條蛇還活著的時候(或者在單人遊戲的情況下把自己玩死了以後)，遊戲就會暫停並呈獻上面這樣的結束畫面。

除了聊天功能依舊提供以外，可以按下 Ctrl+G 來要求再玩一次，若所有玩家都這麼做的話，遊戲就會重新開始。

主持遊戲

在主選單選擇 Create Game 之後就會進入如上圖的畫面，除了預設的空白場景之外，還可以使用上下鍵在程式掃描到的場景檔當中選擇一個來使用，沒有意外的話，列表中應該會有一個遊戲隨附的範例場景可以使用。選擇了場景後按下 Entre 鍵即可進入遊戲，實際上就是程式會在背景執行 snakesd 程式，然後自動連線加入這個伺服器。

除了直接啟動遊戲之外，還可以按下 Ctrl+N 來設定別人會看到的遊戲名稱 (預設是顯示伺服器 IP)；也可按下 Ctrl+D 來設定加入遊戲的密碼，這樣要加入遊戲的人會被要求輸入密碼，只有密碼正確才能加入，這麼做可以防止一些預期之外的閒雜人等加進遊戲。

關於遊戲場景的部份，這個遊戲非常鼓勵玩家發揮創意自製遊戲場景。遊戲場景檔基本就是一個副檔名為 .snksc 的純文字檔案，玩家可以在檔案裡面添加一些特殊物件如牆、滑塊、和隧道等，添增遊戲趣味。具體檔案內容要怎麼編寫，可以直接參考範例場景檔案內的說明，基本上非常簡單！自行製做的遊戲場景檔案只要放置於程式所指定的搜尋路徑下 (或是在 Windows 上直接與主程式放一起)，下次要開遊戲的時候就會被程式搜尋到了。

口罩趣聞

Mon, 03 Feb 2020 12:50:00 +0800

最近武漢肺炎的疫情鬧得臺灣滿城風雨，而今天中午在公司附近吃午餐的見聞讓我實在頗有感觸。

我們公司位在集合式辦公大樓裡，樓下每到中午就是個市集，主要服務晨、午時間出來覓食的上班族。先說說一些大家已經知道的情況，我們這的藥妝店從一早就大排長龍，想都知道等著要買什麼。中午時間裡，熙來攘往的人群中絕大部份是帶著口罩的，說明著確實每個人都擔憂最近的疫情。

但就在經過一個攤位的時候，讓我不經的思索起來。這是個賣饅頭的攤位，除了冷凍饅頭之外，攤桌上也放滿了已蒸熟的饅頭，可供上班族即食。然後眾多顧客在攤前挑選饅頭，不時與老闆隔著中間的饅頭、攤前攤後七嘴八舌的交談。我突然覺得這個畫面好奇怪，稍微深思就讓人啼笑皆非！

戴口罩不就是為了阻隔飛沫傳染嗎？那麼這些承接了灰塵與眾人病毒的饅頭，難道大家買回辦公室會先消毒在食用嗎？這只是一個開始，我再觀察其他攤商也多少存在類似的現象，一邊讓我搖頭嘆息、一邊感嘆教育失敗。因為如果人們真的在乎疫情傳染的話，絕對沒有人敢買陳列在桌上的未包裝食品，一定會吃熟食而避免在市集中採買生菜沙拉與涼麵等餐點。

有朋友提醒了我一句話：「記得多年前的 SARS 好像也沒有像現在這麼誇張，那時候的口罩也沒有如此缺貨！」

對啊！我想起來了，SARS 時期好像真沒有像現在這樣。追根究底，其實是國民的「恐慌感」在作怪。在我看來最近的口罩缺貨情形，其實和稍早之前的衛生紙缺貨本質是一樣的，就是集體恐慌造成的囤貨現象，我猜在這波疫情平息以後，應該有機會在垃圾場看到成箱成箱的未開封口罩被丟棄。

私以為這波疫情可能並沒有大家想像的那麼嚴重，不是告訴大家防疫不重要，而是疫情若真的這麼嚴重的話，很多人早就中鏢了！有沒有看到大家一面戴口罩一面採買市場即食食品？戴口罩露鼻子、或口罩戴在下巴？最後，這就變成了一個大家流行戴口罩、但是實際效用打折的風潮。

Hash Calculation 雜湊計算簡介

Tue, 24 Dec 2019 12:30:00 +0800

雜湊計算是廣泛被應用在數位產業中幾乎是各方各面的一種奇妙的計算工序，它的用法用途上天下地、它的算法千奇百怪、它的面貌千變萬化，對於初次接觸雜湊的學生可能一會兒更難以理解，從而產生它為何出現在此、為何如此計算、為何如此使用等疑問。那麼，本篇就要針對初學電子計算機的人、在首次接觸雜湊計算時充滿了疑惑的人來簡單的介紹雜湊運算帶領入門。

定義

雜湊運算的作用是：對任意長度的任意二進位資料進行計算，並得出一個值域範圍固定的結果數值，對於整個計算包含從開始到最後的結果只有一條硬性規定： 在使用同一種演算法的情況下，對於相同的資料輸入，必須算得一樣的結果數值。

基於這個基本定義，還可以延伸推導出兩個規律：

若兩筆資料計算出的結果值不同，則該兩筆資料必不相同。
若兩筆資料計算出的結果值相同，則該兩筆資料可能相同也可能不相同。

相關名詞解釋：

該計算的結果數值稱為 Hash Value，中文稱為「雜湊值」；
計算該結果的工作稱為 Hash Function，中文稱為「雜湊函式」；
計算該結果所使用的演算方法稱為 Hash Algorithm；
對於兩筆不相同的資料計算出的結果值相同的情況稱為 Collision，中文稱為「碰撞」；
而泛指與之有關的稱為 Hash 或 Hash Calculation，中文稱為「雜湊」或「雜湊運算」。

範例

在對雜湊運算充滿疑惑的狀態下，我覺得與其去研究那些算來算去不知在算什麼的知名演算法，不如先試著自己製做一個雜湊函式，從這當中理解學習雜湊運算可能會更有意義。

要寫作一個雜湊函式其實非常簡單，只要把輸入的資料拿進來，然後發揮你的創意隨便亂算，算出一個和亂數差不多的、無意義的奇怪數字即可。唯一的要求只有一個，那就是使用你的計算方法分別計算兩筆一模一樣的輸入資料，最後得出的那個奇怪數字要是一樣的。另外可能因為這種計算看起來和亂算沒什麼不同，所以當時的人在處理 Hash 的中文翻譯的時候，才給了它「雜湊」這個名字吧！

下面以一個我自己隨便寫的雜湊函式做為範例：

uint16_t MyHashFunction(const void *data, size_t size)
{
    const uint8_t *array = data;

    uint16_t value = 1;
    for(size_t i = 0; i < size; ++i)
        value *= array[i];

    return value;
}

這樣我就完成了一個我自己發明的雜湊計算方法，這個簡單的算法在很多特性方面可能不足以好到讓一般的用途去使用，但卻完完全全符合一個雜湊計算所需的要求。我要求了一筆長度為 size 的位元組資料串做為輸入，最終會算出一個 16 位元、值域範圍為 0 至 65535 的整數值，至於計算方式就是很簡單的把每一個位元組值相乘而已(溢出就讓他溢出，超出的部份就直接捨棄)，其中最重要的是：如果在不同的計算中若你輸入了一模一樣的資料，那麼我就一定會算出一模一樣的結果值。

性能指標

由於雜湊運算的定義要求非常簡單，也鼓勵天馬行空發揮創意，因此現實中使用的各種雜湊演算法實在是滿坑滿谷，而這些不同的演算法之間、甚至是與你自己實現的算法之間有什麼不一樣呢？評估一個雜湊演算法的好壞或者適用與否有幾項主要的性能指標，於下分別說明。

正確性

由於雜湊計算的規定只有一個，所以判斷雜湊演算法正確性的依據也只有一個，那就是我們前面一再強調的：對於同樣的輸入資料必須計算出相同的雜湊值。

既然這條規定是硬性的，不符合這項規定的演算法就不是個合格的雜湊算法，那還有什麼好討論的呢？事實上在這個世界上具名的雜湊演算法可能有 99.99% 都符合正確性的要求，所以這項規範適合的討論範圍其實就是在你們因為各種原因需要自己發明雜湊算法的時候。很多時候演算法正確性不足的缺點可能難在開發的過程中發現出來，比方說在研發人員自己的電腦上怎麼算都正確，但客戶使用產品的時候卻就是會發生運算不正確的情況。比方說研發測試的時候都看不出問題，要換臺電腦、換個系統、換個處理器等等才會發現自己的演算法有缺陷，這種問題特別是在軟體開發人員未具有足夠的資訊概論和程式設計基礎的情況下容易發生 (很符合臺灣產業界的現況)。

記得我畢業後的第一份工作，那時我還是個菜鳥中的菜鳥。有一天我們的軟體需要序號驗證功能，防止客戶無限制的把軟體到處複製使用，這時我主管要我做一個其中需要的函式，用來把用戶電腦的一些關鍵訊息進行各種隨意的亂算，最後算出一筆奇怪的資料。那時的我滿臉問號，不知道這幹什麼用的、也不知道要如何開始，後來他說算了，他來做給我看，最後他開心的展示給我他實現的程式碼。我一邊觀看他一邊解說，反正就是各種隨意的到處亂算，其中最讓我印象深刻的是裡面還用到了 sin 和 cos 等函式。我主管說他們以前遇到這種需求都是這樣做的，反正就是想到的都拉進來亂算，算的愈亂愈好！

經過了多年以後重新回想，我才明白這就是一個需要自行製做雜湊計算的需求，也發現當時的這位研發主管根本不知道雜湊這東西，也不知道世界上早就存在許多比他亂來的實現還要更好的演算法。那麼他的實現哪裡不好呢？撇開各種性能方面的問題不談，就光是要達到計算的正確性這個要求就有問題。例如裡面呼叫了三角函式，而這類的函式實現本身就不能保證絕對可以算出二進位資料完全相同的東西，它的運算結果可能會因為數學函式庫的實做不同而有些差異(這些函式庫通常是由編譯器提供)，就算屏除了函式庫實做的差異，浮點運算在不同的 CPU 上面可能也會有不同的行為表現；我想這可能就是這家公司的程式產品為什麼只能使用 Borland C++ Builder 6 編譯(還不能更新版本)、以及為什麼只能支援 Intel x86 CPU 搭配 Windows 平臺的其中一項重大原因吧！另外，對於數位電腦的基礎知識之不足、以及對於程式設計基本功的馬虎，可能也是導致於這些學長們口耳相傳「即使你不覺得有問題，也絕對不要更換編譯器、絕對不要修改編譯設定、連最佳化編譯也不能打開、絕對打死都不要更動流傳下來的開發環境的任何一個環境設定，否則就會發生千奇百怪的問題」等等這些話語的原因吧！

總結來說，在自己實現雜湊算法的時候需要避免使用某些計算：請避免呼叫那些因為實做不同或版本不同而可能會產生結果差異的函式庫，以免你的演算法只能搭配特定的程式庫或編譯器；請避免呼叫系統 API，以免你的演算法只能在特定的系統下使用；請避免使用浮點數運算、以及整數負值計算，以免你的演算法只能在特定的 CPU 上得到正確的結果；請妥善處理 endian 有關的格式轉換、或採用與 endian 無關的運算，以避免你的演算法依賴於特定的 CPU 格式；以及請避免任何其他以上沒有提到，但會破壞演算正確性的東西，比如有些未知的東西也許會讓你今天計算一筆資料得到結果 27，明天再算卻得到 35 之類的！

不可逆性

如果說雜湊計算是從輸入資料算出雜湊值，那麼逆向的雜湊計算就是從雜湊值計算出原始輸入資料了；而可逆性指的就是從雜湊值回推、或估計、或猜測原始資料可能之組合的可行性，那麼不可逆性愈高自然就表示愈難以從雜湊值逆向推估窺探原始資料。

總體而言，在雜湊計算的定義裡並沒有對可逆或不可逆的特性做出任何要求，在某些用途上可能也不會在意可逆性高或不高，但若所在應用的場景中不樂意讓人從雜湊的結果來窺探原始資料的話，所使用的演算法之不可逆特性就會變得相當重要。

以我的範例來說，它的不可逆性就不夠好，如果算出來的值為零，那麼絕大的機率可能是因為資料中有零的存在，在輸入資料格式已知的情況下，有時就可以猜測某些資料排列組合；若輸入的資料只有一個位元組的情況那更慘，因為這時我的計算結果根本就等於原始輸入資料。

均勻性

一個理想的雜湊算法對於各種輸入資料所算出來的雜湊值，應該平均的分佈在其所定義的值域範圍內，一個結果值的分佈均勻性不佳的雜湊算法，會在某些應用用途上產生不樂見的問題，例如在 Hash Map Container 的應用上會導致性能衰退。

以我的範例來說，它的均勻性就不夠好，雜湊值為零的機率比其他數值都來得高，只要資料中出現了一個零，不論是因為資料本身的零值、還是在計算過程中因為數值截斷的緣故而產生的零值，那麼結果就一定是零了。最終，這個雜湊函式的範例可能只有在輸入資料為長度適中的 ASCII 字串時，才能有較為理想的均勻性表現。

隨機性

雜湊的隨機性指的是對於輸入資料所計算出的雜湊值是否具有規律性而容易被預測的指標，隨機性能愈高的演算法，其所計算的結果愈沒有明顯的規律、愈難被預測。隨機性和均勻性看起來是類似的，然實則有所差異，一個隨機性高的算法未必擁有均勻的算值分佈，反之亦同。

值域範圍

演算法所得之雜湊值值域範圍也是一個很重要的指標，它會間接的影響其他方面的性能表現。雜湊值值域在 0 至 255 之間的演算法，我可以用一個 8 位元整數就能儲存；雜湊值值域再廣一點的，我也許也能用 16 位元、32 位元的數來儲存並應用；但若值域範圍再大上去，當沒有計算機內建整數型態可以容納的時候，對於雜湊值的儲存、運算、和比對等工作所消耗的計算資源可能就會一下子上漲。站在這個考量點上，較小值域範圍、或至少在計算機內建整數型態範圍內的演算法是比較討喜的。

碰撞率

在雜湊運算中的「碰撞」即是用來稱呼當兩筆不同的輸入資料卻計算出一樣的雜湊值的情況，而碰撞率當然指的就是某個演算法是否容易發生碰撞情況的指標。通常來說碰撞率會與均勻性或隨機性等等其他特性連動，總體來說，演算法的碰撞率不是一個單一的性能指標，比較像是整體綜和表現的結果。

基本在所有的應用條件下，人們所喜歡的理想雜湊函式碰撞率是愈低愈好，最好絕對不會發生碰撞；然而實際上碰撞率愈低的演算法往往在某些其他的性能屬性上成績愈不好看，因此在經過權衡取捨後，還是能接受使用一些碰撞率相對高得多的演算法。

以雜湊值值域做為範例，一個值域範圍小的雜湊值可以讓相關的儲存、比對等工作變得容易快速，但是另一方面來看，不管演算法再怎麼厲害，當其雜湊值值域範圍愈低，碰撞率將必然的向上增加。若我要求一個雜湊值範圍在 0 至 255 的演算法，又如何要求它可以在算遍天下資料之後仍不發生碰撞？

運算複雜度

雜湊算法的複雜程度也是一項重要的指標，算法繁複的雜湊函式必然要消耗更多的計算時間才能完成，因此在部份的應用上，也常常選擇那些其他性能看起來沒那麼好但計算快速的雜湊演算法。

應用用途

理想上完美的雜湊演算法各項性能指標都要表現傑出，演算不可逆、算值均勻又隨機、既不可能發生碰撞又只需要內建整數型態即可儲存其值、同時還要實做簡單而運算效率高。無奈這種完美的演算法似乎不可能實現，許多性能指標之間往往互相抵觸，一方面好則另一方面就不可能好。對於不同的用途，重視的性能指標也不一樣，程式開發人員需要依據面對的情況，權衡不同性能指標間的優劣表現，選擇最適合自己的雜湊演算法。因此接下來要介紹在各種常見的雜湊用途中對於演算法選擇的不同觀點，順道介紹雜湊算法常見被用在什麼用途上。

資料校驗

當資料需要在不同的機器之間傳送接收的時候，比如說經過網路傳輸、經過串列埠傳輸等等，偶而會因為一些硬體雜訊還什麼的原因，造成收到的資料有異，這時就要通知對方重送。然而一個很大的問題在於你得要先知到資料發生了異常，然後才知道該進行後續的動作，所以在資料傳輸的用途上幾乎是一定都需要一個資料校驗的機制。

一個簡單的想法是我直接把同樣的資料連續傳個兩三次，如果資料收下來都是一樣的，那就是正確的，反之就表示資料有異。然而這麼做有兩個缺點，首先傳輸的資料量會立刻膨脹兩三倍，白白浪費資料流量空間。第二是萬一遇到問題的發生與通透資料的特性有關的時候，例如某些硬體設計瑕疵導致當傳送了 1、3、5、接著傳送 4 時就會發生資料錯誤，那麼同樣的資料重複送幾次不就都是吻合但卻全部錯誤的嗎？

因此一般我們使用雜湊運算做為資料校驗的手段，對要傳送出去的資料進行雜湊計算得到雜湊值，然後把這個值併到資料裡面一起發送，資料接收方收到資料以後重新計算資料的雜湊值，然後與傳送方夾帶過來的雜湊值比較看看是否一致，若雜湊值相同則可以相信這筆資料絕高的機率是正確的。

在資料校驗的用途上，我們面對的假想情況是整筆資料中的少數幾個位元可能會隨機的發生錯誤的情況，一筆資料的雜湊值也不會需要去和別的資料的雜湊值做比對。因此在演算法的選擇上比較不在意碰撞率和隨機性的表現、對於不可逆性也沒有要求，但通常會很在意運算效率，不希望一筆資料的收送在校驗值上面花費太多的時間和其他計算資源，同樣的也傾向於使用那些值域範圍較小的演算法，以利減少冗餘資料長度並加速計算與比對速度。在資料校驗用途的雜湊演算法一般常見的有 CRC-32、或是更簡單的 checksum 或 LRC 等，甚至在古老的時代理，只有一個位元長度的 parity bit 也是被接受的。

資料索引

在資料結構演算法裡面有一種容器叫作 Hash Map 或 Hash Table，這是一種可用來儲存「鍵值對」資料的容器。我這裡不想要展開解釋太多關於資料結構和容器的東西，那又是另一個大主題了，所以這裡只簡單的帶過一些提示，有興趣的人自己再透過這些關鍵字去查詢更多的細節。當我們需要建立一個資料容器，並且希望可以使用一個關鍵值來找尋容器內符合的資料的時候，除了使用經典而複雜的各種二元樹結構來做以外，也可以使用 Hash Map 容器。使用 Hash Map 的好處是它的實現相對簡單快速，在實際應用上的效能表現通常不俗，在許多需要鍵值容器的簡單執行環境裡有一定的立足位置。

在這種應用場合上，不用說，這演算法的複雜度和計算效能絕對是首要條件，而對於不可逆性和值域範圍等就沒有太多的執著，畢竟值域再大的雜湊值也會因為被取餘的關係而降下來。另一方面，做為容器使用的雜湊算法更看重其均勻性，至於隨機性則不重要。一個算值不均勻分佈的演算法將會容易讓雜湊值集中碰撞在某些區間，導致資料查找效率衰退，最嚴重的情況下會讓 Hash Map 退化為 Linked List。

至於 Hash Map 實際使用的演算法就令人眼花撩亂了，似乎並沒有共識說哪幾個演算法使用率最高，常常是看設計者的想法、以及實際實驗適配以後最終才選擇使用某些演算法，基本上符合上面敘述之特性的演算法都可以放在備選方案裡面。

資料簽章認證

資料簽章認証其實和前面說的資料校驗在概念上是一樣的，都是為了讓資料的正確性受到保障，但更強調接收方所收到(比如從某處下載)的檔案資料是正確且未被竄改過的。其之不同之處在於，相比於資料校驗面對的是資料自然的隨機出錯，資料認証的用途中需要面對並對抗的更多是對於人為刻意而精心竄改的防範。

與資料校驗相同，若人們計算所收到資料的雜湊值與發送方所提供的雜湊值相同的話，基本可以判定該筆資料是正確可受信任的，因為在中間若有資料竄改的情況發生，一般來說這會導致最後計算出的雜湊值不吻合。然而對於一個不夠複雜可靠的雜湊算法而言(例如 LRC)，竄改者可以透過精心設計的內容修改、或者在資料的前後與中間等處插入一些特別設計的垃圾資料，最終讓修改後的內文所計算出的雜湊值與修改前的內文雜湊值相同，導致被竄改的文件受到接收方信任。

因此對於資料認証用途的雜湊演算法選擇上，最看重的是算法要擁有幾乎不可能發生碰撞的極低碰撞率、以及極為隨機的雜湊值分佈，最好是只要改了資料的一小點部份就會造成最終雜湊值十萬八千里的不同，而能夠達成這種要求的演算法基本都是不可逆的。一個符合上述特性的雜湊演算法，可以讓竄改者想要微調控制資料使得雜湊值發生碰撞的情況基本不可能發生，至於演算法的其他的性能指標如運算效率等等一般完全不會有人在意。目前常被使用於資料認証用途的演算法有 MD5、SHA-2 等，此外在各種雜湊演算法列表中若您有看到關於「適合加密使用」等的註記或分類的話，那麼這種演算法就是可以用來做資料認証用途的雜湊算法。如果您曾有在網路上下載檔案時，看到下載處旁邊有一串文字寫著類似「MD5=……」這樣的東西，它就是所謂的驗證碼，下回您可以試著將下載到的檔案用軟體工具計算一下它的驗證碼，再比較看看與網頁上的記載是否相同？

再延伸下去，雖然這一長串的驗證碼可以保證資料的正確性，可是驗證碼本身的可信度呢？我怎麼能確定記載的這個驗證碼是原始作者留的、還是被駭客改過的？如果說驗證碼保障了資料的話，那麼誰來保障驗證碼呢？對於這樣的需求發展出來的解決方案，一般是使用了公鑰加密技術，用原作者或發佈者的私鑰將驗證碼加密起來，這樣任何人都可以用發佈者的公鑰解密出驗證碼，並且只有使用了正確的公鑰才能夠解密出正確的驗證碼，讓竄改者無從下手。對於這種經過加密的驗證碼，我們一般稱之為「簽章」，如同現實世界手寫簽名的數位版本，任何人都可以透過公鑰系統搭配雜湊算法，驗證某筆檔案或資料是否確為某個人所簽名發佈並且未經竄改。

資料隱藏

當我們想要隱藏一些不想讓別人知道的資料時，直覺想到的方法大概就是加密了吧！然而有時候我們可以使用雜湊計算來隱藏資料，除了比一般的加密算法更簡單快速以外，還不用費心在管理和保護加密密鑰的工作上。當然，使用雜湊計算來隱藏資料有一個明顯的缺點，就是無法回復資料，因此只適合用來隱藏那些不需要解密的資料。那麼實際上有這種不需要解密的資料隱藏需求嗎？答案是有的，比如密碼的加密。

在很多時候我們會需要對使用者進行密碼驗證，比如說網站的密碼登入、電腦的密碼登入等等，如果我們把使用者設定的密碼資料直接明碼儲存在網站資料庫、或者電腦系統的檔案系統內的話，那麼就會存在很大的風險，一旦資料庫被入侵竊取的話，所有使用者的密碼就一覽無遺。一個普遍被使用的保護方法是我們不直接儲存密碼，我們將密碼做為輸入資料計算出該密碼的雜湊值之後，只儲存這個雜湊值。這樣雖然無法還原出原本的密碼，但卻完全不影響密碼機制的使用，因為我們只要對使用者輸入的密碼進行一樣的雜湊計算得到雜湊值，然後比對和資料庫中儲存的雜湊值有沒有一樣，就知道密碼是否正確了。相對的，就算有人從資料庫中取得了這些雜湊資料，也無法知道密碼是什麼？只能使用暴力破解法一個一個去嘗試！

對於資料隱藏用途的雜湊演算法挑選，一般完全比照資料簽章認証的標準，一樣使用加密類型的雜湊算法。

產生密鑰

雜湊計算除了通常用來把一筆很長的資料計算為很短的雜湊值之外，也可以用來將很短的資料變成長度比較長的雜湊值。

舉例來說，學過加密算法的人大概都知道加密金鑰長度通常都在數百位元的大小，可是我們常用的文件加密、壓縮檔加密等等都只需要設定相對短得多的密碼，甚至密碼只有一個字母也行，那麼這麼短的密碼怎麼能夠用來當作加密金鑰使用呢？這時候雜湊計算就派上用場了。比如說我們使用 MD5 將用戶輸入的密碼計算為 128 位元的雜湊值，正好符合 AES 加密的最短金鑰長度，這樣使用者不管設定了多短、或多長的密碼，我都可以計算得到一個足夠我使用、且看似亂數的金鑰；並且最重要的是，只要輸入了同樣的密碼，我一定可以算出同樣的金鑰。

對於金鑰產生用途的雜湊演算法挑選，可完全比照資料隱藏的標準，一樣使用加密類型的雜湊算法。

與其他一些看起來類似的計算不一樣的地方

在完成了雜湊計算的介紹和比較之後，最後我還想順便針對初學者補充一些資料，解釋有些看起來與雜湊計算相似(或雜湊計算與之相似)的計算工作之間的差異。

亂數

亂數產生就是產生一個隨機的亂數，而雜湊計算也是算出一個看起來隨機的亂數，那麼此二者之間的差別在哪裡呢？

相比於雜湊計算，亂數的計算強調的是絕對的隨機性和均勻性。除此之外，亂數與雜湊之間最大的差別還在於，雜湊計算雖然最終也是算出無法預測的隨機數值，但是只要輸入的資料相同，則最終的這個隨機數值也會是一樣的。相反的，亂數計算以能夠算得最亂最無法預估的數值為目標，即便目前的偽隨機亂數演算法當中只要輸入相同的狀態資訊則亦能算得一樣的亂數值，但這比較像是迫於現實無奈之下的結果，而非偽隨機亂數的本意。

另外，雜湊演算法要求在各種軟硬體計算環境下都能算得一樣的結果，而亂數生演算法則對不同環境下造成的計算差異不太看中，甚至有些亂數生成工作還會刻意把一些無法預測的硬體雜訊湊進來計算，只為能夠算出更亂更無法預測的結果。

加密

前面提到，雜湊可以用來隱藏資訊變成好像隨機亂數的資料，而加密計算也是能夠把資訊隱藏變成好像隨機亂數的資料。

然而它們之間的不同比較容易分辨，雜湊與真正的加密行為之間最大的不同在於，加密算法可以把資料從隱藏狀態下還原，而雜湊不行！因此雜湊計算只能用來將資料隱藏之後做為比對等用途使用。但也因為雜湊計算不要求能夠還原資料的原因，雜湊計算通常會比真正的加密計算來得簡單快速得多，也避免了使用加密機制所需要的密鑰管理保護工作。

參考資料

使用 gettext 方案製做多國語系程式 - 製做語系檔

Fri, 08 Nov 2019 14:35:00 +0800

當我們依據 gettext 的規範修改我們的程式碼後，接下來就可以使用 gettext 的各種工具掃描分析、加入翻譯資料、並最終產生語系資源檔了。

本篇將針對程式開發人員建置專案工作的部份，以一個範例來描述如何從分析專案程式碼到最終生成語系檔案的工作。

上面流程圖簡單扼要的說明了從分析程式碼到最終產出語系資源檔的流程、工具、和產生的各種檔案，但對於初次接觸的人可能還是稍嫌複雜，因此接下來我要稍稍解釋它們，使其對初學者較容易理解記憶。

生成的檔案類型

整個處理文字翻譯的過程中大約會產生 .pot、.po、和 .mo 三種檔案，分別解釋如下：

PO (Portable Object)

該檔案就是在整個翻譯過程中最重要的檔案，每一個(要支援的)地方語言就需要(至少)一個對應的 PO 檔，這個檔案是語言文字翻譯翻譯人員直接面對的一個文字檔，裡面記載著大量原始文字對應到某個特定語文文字的資料條目、以及其他有用的註解訊息。
MO (Machine Object)

應用程式若直接讀取解析 PO 檔案的話，會消耗比較多的系統資源，因此實際上由應用程式直接取用的是經過編譯後的二進位文件，也就是 MO 檔，而這也就是在本系列文章中所稱呼的語系資源檔。
POT (Portable Object Template)

因為每一種語言都需要一個與之對應的 PO 檔，因此實際上可能會存在數量龐大的 PO 檔群。 PO 檔最初是由解析工具掃描整份專案程式碼檔案而來，那麼多次重複掃描一樣的文件以產生不同語系的 PO 檔就顯得不太有效率。因此實務上通常只會進行一次掃描解析工作來產生一個通用的樣板檔案，再用這個通用檔案去變化成每個具體語系所使用的檔案，而這個通用的樣板檔案就是 POT 檔。實際上 POT 和 PO 的格式一模一樣，其檔案的初始內容也幾乎相同。

生成檔案的步驟

在了解各種檔案的用途後，接下來以一個範例解釋產生它們的流程步驟：

使用 xgettext 程式掃描整個專案的程式碼以產生 POT 檔：
```
xgettext \
	--package-name=gettext-demo \
	--package-version=v0.1 \
	--copyright-holder=Testman \
	-c+ \
	-k_ \
	-o demo.pot \
	demo_part1.c demo_part2.c ...
```
常用選項：
- -o FILE: 指定輸出檔名。
- -cTAG: 將程式碼內以 TAG 做為開頭的註解一併寫到 POT 檔案裡，這些註解可能可以幫助翻譯人員進行翻譯時閱讀參照。因此需要與程式開發人員協調出一個約定的符號，讓開發人員為那些他們覺得可能會對翻譯有所幫助的註解說明加上這個約定的符號。在這個範例裡，我們使用「+」符號。
- kWORD: 除了 gettext 以外，也一併將 WORD 視為關鍵字搜尋程式碼檔，這個功能在使用了自定義的 gettext 別名的時候有用。在這個範例裡，我們一併將底線符號「_」視為關鍵字搜尋。
- --package-name=PACKAGE: 設定這個程式專案的名稱，不設也不影響後續流程。
- --package-version=VERSION: 設定這個程式專案當前的版本號名稱，不設也不影響後續流程。
- --copyright-holder=STRING: 設定版權所有人或單位的名稱，不設也不影響後續流程。
使用 msginit 讀取 POT 檔來產生 PO 檔(適合第一次產生該語系 PO 檔時使用)：
```
msginit -l zh_TW.UTF-8 --no-translator -o demo-zh_TW.po -i demo.pot
```
常用選項：
- -i FILE: 輸入的 POT 檔。
- -o FILE: 輸出的 PO 檔；若不指定輸出檔，則預設會以 locale 名稱產生輸出檔；若設輸出檔為 - 則會從 standard output 輸出結果。
- -l LL_CC: 指定的語系，格式為 <LOCALE>_<COUNTRY>[.<ENCODING>]。雖未要求輸入 encoding，但在沒有 encoding 的情況下產生的檔案 encoding 通常是 ASCII，此時若在翻譯檔內輸入非 ASCII 的文字 — 比如說 UTF-8 格式的中文 — 則會在後面編譯時產生錯誤；雖然這個 encoding 可以在文件產生後再手工修改 charset 欄位，但若閒麻煩的話就可以在產生 PO 檔的時候直接指定 encoding。
- --no-translator: 不設定翻譯者資訊，產生的 PO 檔相關欄位會被設為 "automatically generated"；若不使用這個選項，則程式會交互式詢問翻譯者名稱和信箱，可能不利自動化腳本，因此一般建議翻譯者資訊由翻譯者在 PO 檔內自行修改。
使用 msgmerge 更新 PO 檔(適合更新已有的語系 PO 檔時使用)：
```
msgmerge -U --backup=off demo-zh_TW.po demo.pot
```
除了第一次產生某個語系的 PO 檔之外，比較常遇到的情況應該是程式有修改更新，而可能會多出一些需要翻譯的文字。此時若使用 msginit 每次都重新產生 PO 檔然後全部翻譯重來一遍的話，應該會讓翻譯人員吃不消！這時改用 msgmerge 來產生合併後的 PO 檔，即保留原有的翻譯、並加入新的條目，就會是比較合適的做法。

常用選項：
- -U: 直接將更新後的結果寫回 PO 檔；若沒有其他設定要求，則會產生一個原檔案的備份檔。
- -o FILE: 指定輸出檔名；若不指定輸出也沒有設定更新，則會將結果輸出到 standard output。
- --backup=off: 在更新模式下不要產生備份檔。
人工修改 PO 檔資訊、增加翻譯字串：

這個步驟其實沒有建置人員的事情，只要把新產生的 PO 檔交給翻譯人員處理，或者將翻譯人員提交的 PO 檔合併進來，就可以了。有關於 PO 檔案的格式內容、以及該如何編輯的部份到後面再做解釋。
使用 msgfmt 讀取 PO 檔以產生 MO 檔：
```
test -d locale/zh_TW/LC_MESSAGES || mkdir -p locale/zh_TW/LC_MESSAGES
msgfmt -o locale/zh_TW/LC_MESSAGES/demo.mo demo-zh_TW.po
```
常用選項：
- -o FILE: 指定輸出檔名。
- -a NUMBER: 設定資料對齊 NUMBER bytes。視 gettext 執行時庫的實做而定，將對齊設為適合目標平臺 CPU 的數值，對於加速 MO 檔內資料查詢可能有幫助。 (default: 1)
- --endianness=BYTEORDER: 設定使用的 endian 格式， BYTEORDER 可為 big 或 little。將 endian 設定為與目標平臺相同，則可能可以加速一點點在應用程式讀取 MO 檔時的速度。 (default: same as platform)

發佈 MO 檔

編譯完成的 MO 檔就可以發佈出去了。由於 MO 檔本身與平臺無關，因此同一個 MO 檔可以拿到所有的平臺下使用，而無需重新編譯為個別平臺下使用的版本。

也由於 MO 檔本身獨立於應用程式執行檔之外，是由應用程式通常在程式起始時載入，就算載入失敗或找不到檔案也不會讓程式當掉或發生其他異常，就只是等於沒有翻譯而已；就算 MO 檔內沒有完整記載程式所有需要翻譯的字串資料(也就是還沒翻譯完的意思)，那就是在程式中的部份字串會以原始字串呈現而已。因此 MO 檔本身的使用彈性很大，可以獨立於執行檔進行更新升級以補充或修正翻譯條目，也可以直接加入原來沒有的新語系的 MO 檔，就可以讓應用程式支援這個語系。

那麼 MO 檔究竟要放到哪裡去呢？答案是個別的 MO 檔最終要放到下面這個位置：

<RESOURCE-DIR>/<LOCALE>/LC_MESSAGES/<DOMAIN>.mo

其中：

<DOMAIN> 通常就是專案名稱或程式名稱，實際要與開發人員協調約定；
<LOCALE> LL_CC 格式的語系名稱，例如 zh_TW；
<RESOURCE-DIR> 是所有語系的 MO 檔會放置的共同目錄，在 Linux 上面通常就是 /usr/share/locale，實際要與開發人員協調約定，比如說可能是執行檔所在目錄下的 data 資料匣等等。

假設我們的範例使用了 Linux 上的一般慣例，那麼我們編出來的臺灣中文的 MO 檔就應該要放在下面這個地方：

/usr/share/locale/zh_TW/LC_MESSAGES/demo.mo

然而為了方便測試的緣故，本系列文章的範例實際使用的是工作目錄下的 locale 資料匣，我們的 domain name 設定的也是 gettext-demo 而非 demo。那麼假設你會在家目錄下的 demospace 目錄下執行範例程式的話，那麼我們的臺灣中文 MO 檔就應該要放在：

~/demospace/locale/zh_TW/LC_MESSAGES/gettext-demo.mo

PO 檔案內容

PO 檔可說是整個流程所生成的檔案中最重要、富含最多訊息，並且也是翻譯人員直接面對的檔案，因此有必要說明一下這個檔案的格式和內容。下面我們先來看看本文所範例所使用的 PO 檔案內容：

# Chinese translations for gettext-demo package
# traditional Chinese translation for gettext-demo.
# Copyright (C) 2019 Testman
# This file is distributed under the same license as the gettext-demo package.
# Automatically generated, 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: gettext-demo v0.1\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-11-11 09:43+0800\n"
"PO-Revision-Date: 2019-11-11 09:43+0800\n"
"Last-Translator: Automatically generated\n"
"Language-Team: none\n"
"Language: zh_TW\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: gettext-demo.c:66
msgid "This is a simple message."
msgstr "這是一個簡單的訊息。"

#. + This is a special comment that will be output to the PO file.
#: gettext-demo.c:70
#, c-format
msgid "I will go to %s by %s.\n"
msgstr "我要搭%2$s去%1$s。\n"

#: gettext-demo.c:70
msgid "Taipei"
msgstr "臺北"

#: gettext-demo.c:70
msgid "bus"
msgstr "公車"

翻譯條目

PO 檔主要記載著大量翻譯條目，也就是成對的 msgid 和 msgstr 標籤，分別對應原始字串和翻譯後字串，原始字串內容由解析程式生成，而翻譯字串內容則是由翻譯人員填寫；若翻譯字串(msgstr)的內容為空的話，則該條目就不會被編進 MO 檔，應用程式最終就會顯示原始字串。

msgid "This is a simple message."
msgstr "這是一個簡單的訊息。"

以上面條目為例，這個條目的 ID 就是 msgid 的內容即 "This is a simple message."，而對應的翻譯為 msgstr 內容，原本是空的，因此由我寫上 "這是一個簡單的訊息。" 這個翻譯結果。

檔頭資訊

PO 檔案頭部有一個特別的空字串 ID，其所對應的內容實為語系檔案相關資訊註記，供後續處理程式所用。其中大部份資訊是由程式所產生，一般不需理會，只有部份的資料內容可能需要翻譯人員或建置人員修改更新其內容 (雖然多半不改也不會影響後續檔案產生流程)，例如：

Project-Id-Version 標籤後面的 PACKAGE 和 VERSION 應更改為專案或程式名稱、以及其版本。
Last-Translator 標籤後面應填寫翻譯者姓名和信箱。
charset 標籤後面要修改為所使用的編碼格式 (如果在產生 PO 檔的時候沒有指定文字編碼的話)。

註解與特殊註解

PO 檔內以「#」開頭的那一行文字就是是註解訊息，一般的註解會被後續處理程式所忽略；然而那些在註解符號後面不是空白，而是緊跟其他符號的註解，則為提供後續處理程式、或翻譯人員所使用的特殊資訊，例如：

#. + This is a special comment that will be output to the PO file.
#: gettext-demo.c:70
#, c-format
msgid "I will go to %s by %s.\n"
msgstr "我要搭%2$s去%1$s。\n"

#. 表示這是從程式碼中掃描出來的特別的註解，可能是程式人員認為對翻譯有幫助的說明。
#: 記載該原始字串出現於程式碼的位置，以利在需要的時候直接向開發人員查詢相關疑惑。
#, 表示這是供 MO 產生器使用的資訊，其後面文字可能為：
- fuzzy：該註記可能由翻譯人員加上，表示該翻譯可能不正確或還存在爭議，暫不將該條目編入 MO 檔。當翻譯結果確認無誤後，由翻譯人員把該註解刪除即可。
- c-format：表示翻譯字串內含有 C 語言的 printf 類函式的格式字。若程式的執行環境為 UNIX 相容平臺，還可以使用特別的 1$、2$ 等符號標記來變更後面參數出現的次序，這樣就可以因應不同語言的語法順序可能不一樣的狀況來調整挪移文句，詳請參閱範例程式。

PO 檔相關工具

理論上在此之前的說明已經足以從頭到尾完成整個翻譯檔案產生的流程了；然而如同我們在系列文章中一直強調的，在實際的專案上，人們經常面對的是內含大量翻譯條目的 PO 檔，其中有些已翻譯、有些未翻譯、有些還待確定，同時程式本身也在修改，時不時會多出一些新的待翻譯條目(或可能會少一些條目)。那麼翻譯人員就要在成千上萬行的 PO 檔裡面到處人工閱覽搜索，再補上需要的翻譯？當然不是！因此接下來就要介紹一些專門用來分析處理 PO 檔的工具程式。

potool

potool 是廣泛被使用的 PO 檔分析處理工具，使用套件管理工具的話只要安裝 potool 套件即可。 potool 主要提供三支程式：

potool

這是最主要的程式，有兩種工作模式(至於使用參數選項則太多，詳請參閱該程式說明文件)：
- Filter Mode: 當只有輸入一個 PO 檔時為 filter mode，作用為依指定的條件過濾並輸出檔案內的條目。
- Merge Mode: 當輸入兩個 PO 檔時為 merge mode，作用為將兩個檔案內容合併，類似於 msgmerge 的工作。
postats

這是 potool 程式的再包裝腳本，用以分析並輸出 PO 檔的統計資訊如已翻譯條目、未翻譯條目、完成比例等，簡單用法如下：
```
postats FILE.po
```
poedit (potooledit)

這是 potool 程式的再包裝腳本，會讀取並只顯示尚未完成翻譯的條目讓使用者編輯後回存。 potooledit 是這支程式的另一個別名，為避免與其他也叫作 poedit 的程式發生同名衝突而設！簡單用法如下：
```
poedit FILE.po
```

potool 雖然小巧便利，但因是指令列工具，要讓一般的文字翻譯人員平常使用的話可能還存在一些難以跨越的門檻。 potool 一般的用途比較多是用來自動分析專案內的語系翻譯進度等資訊，或者程式人員小規模修改翻譯條目時所使用。

GUI 程式

除了指令列程式以外，一般的語言翻譯人員可能更喜歡使用方便直覺的 Desktop GUI 程式。這裡推薦使用簡單容易上手的 Poedit (基於 wxWidgets)、或者還有可能有點複雜但功能非常強大的 OmegaT (基於 Java)，他們都是跨平臺的自由軟體。

使用 gettext 方案製做多國語系程式 - 程式編寫

Fri, 08 Nov 2019 14:30:00 +0800

首先，若應用程式的程式碼本身不支援任何一種多語系工具的設計的話，那麼後面就什麼都沒得玩了！這樣的程式肯定是無法支援不同語言的切換顯示行為。因此對於一個想要支援多語系的專案而言，需要進行的第一步就是修改專案程式碼，使其可以支援所使用的多語系工具進行後續處理、翻譯、和發佈等工作。

本篇將針對程式開發人員編寫程式碼的部份，以一個範例來描述如何修改程式碼以支援 gettext 多語系方案的工作。

程式碼中使用 gettext 大概分為兩個部份，分別是：在程式碼中使用 gettext 的功能來標記需要翻譯的字串、以及載入所需要的語系檔案資料，以下將分別進行描述。

程式碼中使用 gettext 提供的功能

程式碼裡面所有需要被翻譯的文字都要特別標記起來，這樣後續工具才能知道哪些地方需要翻譯處理。標記的方式是將需要翻譯的字串放進「gettext( )」裡面，例如將：

const char *message = "This is a simple message.";

改成：

const char *message = gettext("This is a simple message.");

gettext 有兩個作用，在後面使用翻譯工具解析檔案時，會以該關鍵字抓出所有需要翻譯的字串。而在程式執行時期，gettext 其實就是個函式(需要引用 libintl.h)，它會以傳入的字串做為 ID 來尋找並傳回對應的翻譯字串；若找不到對應的字串、或根本語系資源檔就沒有成功載入，則便會將輸入的字串直接傳回，也就是形同沒有翻譯的意思。

使用原始字串作為 ID 的好處是，程式開發人員只管標記需要翻譯的字串，不需再為每一個字串想一個 ID；但也由於原始字串會被程式庫當作 ID 使用，因此建議原始字串使用比較單純、沒有什麼編碼爭議的語言，通常會建議使用英文。

有鑑於 gettext 這個關鍵字本身可能單字長度太長，會太影響程式碼版面，有時人們會在程式碼裡定義一個更簡單簡短的別名，最常見的大概就是一個底線符號「_」了，例如：

#define _(str) gettext(str)

......

const char *message = _("This is a simple message.");

當然若這麼做的話，後面在使用解析程式時就要記得通知它需要一併搜尋我們所定義的符號，這個問題到後面相關部份再描述。

除此之外，有時候程式碼裡面可能會有一些只光看字串難以理解其意義，讓翻譯人員不知該如何翻譯的字串，這時就需要由開發人員寫上一些合適的解釋註解，讓後面翻譯人員可以參考閱讀。問題是一般的註解通常都會被任何工具直接忽略，那該怎麼辦呢？這裡就要介紹 gettext 工具有一個特別的設計，他在掃描解析程式碼的時候，會把那些以約定的符號做為開頭的註解一併掃描進來使用。這樣程式人員在寫出可能會讓翻譯人員糊塗的字串時，就可以以特別的符號做為開頭，寫出可供翻譯人員參考的註解說明，例如：

//+ This is a special comment that will be output to the PO file.
printf(gettext("I will go to %s by %s.\n"), _("Taipei"), _("bus"));

在這個範例裡，我們約定以加號「+」起頭的註解是需要被掃描的註解，然而實際上這可以是任何符號、也可以是多個字元，重點是與開發人員約定好要使用什麼符號做為註解開頭即可，後面在使用 gettext 掃描工具時，再透過選項來告知掃描工具我們所使用的特殊註解開頭符號是什麼就可以了。

載入語系資源

當然，我們必須要先載入正確的語系資源檔案，後面也才有資料能夠讓 gettext 函式來搜尋取用，這部份的工作通常會被併入應用程式初始化工作的一部份。設定以及載入語系資源檔案主要由先後呼叫幾個函式完成： setlocal、putenv、bindtextdomain、和 textdomain。

#include <locale.h>
setlocale(LC_ALL, "");

首先使用 setlocale 設定程式要使用的 locale。函式需要輸入所要使用的 locale 名稱，理論上這個名稱的格式是由作業系統決定的，但因為 gettext 大多使用在 Linux 上，因此我們也習慣使用 LL_CC 的格式，例如要設定使用臺灣中文的話就需要輸入 zh_TW。除了指名使用的 locale 名稱外，一般我們會直接輸入空字串，直接套用系統當前的語系設定；而這就是為什麼 Linux 下的軟體大多不用特別設定使用的語言，軟體就會自動依據使用者的語系設定顯示該語系文字的原因。

char langenv[64];
snprintf(langenv, sizeof(langenv), "LANGUAGE=%s", setlocale(LC_ALL, ""));
putenv(langenv);

此外，在有些版本的 Linux 平臺上，可能會若遭遇無法成功載入正確的語系檔，這時也許就需要一併設定 LANGUAGE 環境變數。

#include <libintl.h>
bindtextdomain("gettext-demo", "/usr/share/locale");

再來是使用 bintextdomain 設定語系資源檔所在位置、以及 domain name。先說 domain，各程式可能都會有各自的翻譯，為了將它們良好的區隔，以致不會互相混淆覆蓋，我們需要為應用程式的語系資源檔取一個 domain name，對於絕大部分的情況下，建議直接使用應用程式的名稱就可以了。

此外我們還要告訴程式庫我們的語系資源檔案所存放的位置。對於設計在 Linux 上面運作的程式來說，在絕大部分的情況下直接把這個目錄設為 /usr/share/locale 即可；對於其他情況，我們就需要計算並設定一個我們實際放置語系資源檔的位置，例如後面的完整範例裡，我就設定使用了當前工作目錄下的 locale 資料匣，而在發佈於 Windows 平臺上的程式，我習慣把語系檔案放在該程式所在目錄下的 locale 資料匣。

#include <libintl.h>
textdomain("gettext-demo");

最後我們使用 textdomain 完成語系資源檔案的載入。 textdomain 函式需要傳入所要使用的 domain name，也就是之前我們呼叫 bindtextdomain 函式時所傳入的 domain name。

然後程式庫會依據我們前前後後所設定的各種資料來計算出要載入的語系檔案，最終被載入的語系檔案為：

<RESOURCE-DIR>/<LOCALE>/<CATEGORY>/<DOMAIN>.mo

其中：

<RESOURCE-DIR> 是我們呼叫 bindtextdomain 時所設定的路徑；
<LOCALE> 是我們呼叫 setlocale 時所設定，或由系統取得的 locale name；
<CATEGORY> 一般就是 LC_MESSAGES，作者我孤陋寡聞，還沒看過有其他的情況；
<DOMAIN> 就是我們呼叫 bindtextdomain 時所設定的 domain name。

以我們前面的範例來說，最終它載入的語系資源檔案可能就是：

/usr/share/locale/zh_TW/LC_MESSAGES/gettext-demo.mo

編譯與執行

編譯這個範例程式碼很簡單，只需把後面的完整範例程式碼存檔為 gettext-demo.c，然後執行下列指令：

gcc -o gettext-demo gettext-demo.c

就如同編譯一般的程式一樣，如同從前所述，gettext 相關程式庫已被併入 Glibc，所以不需要再額外做什麼。那麼如何執行呢？只要這樣即可：

./gettext-demo

當然，現階段不管怎麼執行它跑出來的都會是英文，那是因為我們還沒有進行翻譯的工作、也還沒有把語系檔放在正確的位置，這個部份在下篇會做解釋。

當我們完成了翻譯檔之後，若要測試成果的話，除了更改使用者語系然後重新登出登入再執行程式外，其實還可以透過程式環境變數簡單的改變程式所使用的語系，例如使用下列方法強制程式在 en_GB 語系下運作：

LANUGAGE=en_GB ./gettext-demo

完整範例程式碼

#ifdef NDEBUG
#   undef NDEBUG        // To force enable assert.
#endif

#include <assert.h>     // To use assert, For test use.
#include <locale.h>     // To use setlocale.
#include <stdio.h>      // To use printf.
#include <stdlib.h>     // To use putenv.
#include <unistd.h>     // To use getcwd, for test use.
#include <libintl.h>    // To use bindtextdomain, textdomain, and gettext.

#define _(str) gettext(str) // Tips: Use this define to short the "gettext" statement.

int main(int argc, char *argv[])
{
    printf("---- setting environments begin ----\n");

    /*
     * First, calculate the locale resource path.
     * This is designed for "testing in any path by any user" purpose
     * and may not be needed for the real application.
     * Normal applications usually use the absolute path, for example:
     * /usr/share/locale
     */

    char cwd[FILENAME_MAX];
    assert(getcwd(cwd, sizeof(cwd)));
    printf("CWD: %s\n", cwd);

    char locale_dir[FILENAME_MAX];
    snprintf(locale_dir, sizeof(locale_dir), "%s/%s", cwd, "locale");
    printf("Locale DIR: %s\n", locale_dir);

    // Setting locale.
    const char *locale_name = setlocale(LC_ALL, "");    // Using system locale setting.
    printf("Set locale: %s\n", locale_name);
    assert(locale_name);

    // Setting language environment variable.
    char langenv[64];
    snprintf(langenv, sizeof(langenv), "LANGUAGE=%s", locale_name);
    putenv(langenv);

    // Define the domain name.
    // It is recommended to use the application name.
    static const char *domain = "gettext-demo";

    // Locate the path of locale resource files.
    const char *binded_dir = bindtextdomain(domain, locale_dir);
    printf("Bind DIR: %s\n", binded_dir);
    assert(binded_dir);

    // Load the locale resource file.
    // Which file will be loaded is:
    // <LOCALE-DIR>/<LANGUAGE>[_<COUNTRY>]/<CATEGORY>/<DOMAIN>.mo
    // for example:
    // /usr/share/locale/zh_TW/LC_MESSAGES/vlc.mo
    const char *curr_domain = textdomain(domain);
    printf("Load text: %s\n", curr_domain); // The domain can be NULL to
                                            // use the previous setting.
    assert(curr_domain);

    printf("---- setting environments end ----\n");
    printf("\n");

    /*
     * Now start using gettext functions.
     * Every strings which be embraced by "gettext"
     * will be marked then try to translated.
     */

    const char *message = gettext("This is a simple message.");
    printf("%s\n", message);

    //+ This is a special comment that will be output to the PO file.
    printf(gettext("I will go to %s by %s.\n"), _("Taipei"), _("bus"));

    return 0;
}

使用 Gettext 方案製做多國語系程式 - 總覽

Fri, 08 Nov 2019 14:25:00 +0800

有時候程式寫著寫著一不小心生意愈做愈大，常常就會需要面對不同語言文化客戶的問題，也就是「國際化與地區化」的議題(Internationalisation and Localisation)，而這些問題中的第一個需要解決的問題常常就是：如何讓我的程式可以切換顯示各國語言的文字？對於這個問題，我要介紹使用的是 gettext 方案，這是在自由軟體以及 UNIX 平臺上廣泛被使用的方案。

方案比較

讓應用程式支援多國語系的解決方案可能有很多不同的方式，那麼為什麼我推薦 gettext 方案呢？這裡就要來比較 gettext 在一些常見的方案中有哪些突出的優點？對於桌面三大平臺：在 Linux 和其他 UNIX like 平臺上使用比例最高的就是 gettext 方案，好像也就沒什麼好比較的；在 OS X 平臺上，我對 Apple 的東西涉略不多，難下論斷，但既然 OS X 繼承自 Free BSD，那麼理論上應該也可以使用 gettext 無縫接軌；因此最後會發現，似乎只有在 Windows 平臺上才有不同方案比較的意義，所以接下來就來就來看看在 Windows 上面可能常見到的多語系開發方案。

不像在 Linux 下被 gettext 統一天下， Windows 平臺下的多語系支援方案比較凌亂，各種解決方案百花齊放。這可能是因為微軟主推的方案太過繁複，然後其他的方案又都有一些窒礙難行的地方，沒有誰能夠大大的優於另外一個，最終導致各種稀奇古怪的方案充斥的結果。在這些方案當中，比較常見的一些如下：

INI 類文字檔

做法最簡單也很常見的一個方案是把程式中使用到的各種文字編為 ID，然後把這些 ID 和對應的實際文字寫在一個 INI 檔案 (或其他格式文字檔案、這裡僅以 INI 為代表)，實務上有人為每一個支援的語言各建立一個 INI 檔，也有人把所有支援語言的文字編在同一個 INI 檔(這時就要注意編碼問題 ^_^)。當程式執行時，首先依據自身設定載入對應的 INI 檔案，然後在後面程式運作的途中需要輸出文字時，就查詢並取用 INI 檔內的字串即可，例如「INI 多國語言介面」。

這個方案的優點是簡單容易實現，而且似乎不管什麼樣的程式、什麼樣的平臺都可適用；然而缺點是缺乏現成的相關處理工具。

要知道一個在具有一定規模的實際專案中，所使用的字串數量成千上萬，並且隨著程式的開發過程可能還會不斷變化，那麼翻譯人員難道要手工搜尋處理這樣龐大且隨時變化的文字檔？通常我們會希望透過一些處理工具來輔助翻譯人員，至少能夠執行合併新舊翻譯檔、區分已翻譯和未翻譯條目等等工作；可是因為整個文字檔的格式內容是自訂的、載入以及使用方式也是自己設計的，因此可能沒有現成的工具可以處理這些工作，那麼要不就是需要自己開發相關工具，要不就是讓翻譯人員全手動處理翻譯檔！

這些因素使得 INI 方案只適用於不那麼複雜的小型程式、或者缺乏開發資源的專案 (不過就苦了翻譯人員了，雖然在缺乏開發資源的情況下通常程式開發和翻譯會是同一票人)。
Windows 資源檔

對於熟悉 Windows 程式開發的人可能多半知道， Windows GUI 程式有一個特別的「Windows 資源檔」這種東西，還要用資源檔編譯器編譯後再連結到最終的程式。微軟對於多國語系開發的部份主打使用資源檔，就是將所有程式中使用的字串都編到資源檔裡面去，執行時期再透過 ID 來找對應的字串，概念上與使用 INI 檔類似，只不過把 INI 檔換成資源檔。

這麼做的好處除了微軟在官方文件上對於多語系程式推薦使用這種方式、以及可以把程式全包成一個執行檔而不用附帶一大堆檔案以外，似乎就沒再有什麼太大的優點。使用 Windows 資源檔做為多國語系解決方案倒是存在不少缺點：
- 當人們需要增加一些翻譯字串、或想要擴充支援原來沒有被支援的語言時，需要修改資源檔並重新編譯程式。
- 除了使用 Visual Studio 以外，有沒有什麼好的資源檔編輯器？要知道一般的翻譯人員可能通常不會寫程式，難道要先教會他們使用 Visual Studio？
- 如果開發的程式不是 MFC 或 WTL 專案，能夠簡單順暢的使用資源檔嗎？
- 如果不使用 Visual C++ 編譯器的話，能夠簡單順暢的使用資源檔嗎？
- 既然 Windows 資源檔是 Windows 下特有的產物，那如何面對跨平臺程式開發的需求？
此外，若專案沒有建基在 Unicode 環境的話，還會面臨一些嚴重的問題。我在剛畢業的時候負責開發維護一個建立在 Borland C++ Builder 6 下的專案，就是使用 Windows 資源檔以及一些小腳本處理多國語言的問題，我們還做了一些工具用來掃描 DFM 檔案並生成翻譯用的 Excel 檔，再把 Excel 檔內容取出並覆蓋回 DFM 檔和 RC 檔。那時我們的程式主要需要中文、簡中、和英文版本，為此我們需要編出三套執行檔。英文的部份在任何語系下都能被支援，但為了編譯 GBK 編碼的資源，我們需要重新開機到簡中環境下編譯這部份的程式碼，然後再重開機回來進行程式打包工作，你看那如果我們要支援更多一點語言的話不就忙死了！我後來寫了 batch 腳本處理各種工序，使得一個按鍵可以完成絕大部分的編譯打包工作；只是碰到需要切換語系並重新開機的部份就沒輒了，整個程序最終仍然無法一鍵完成。

有人會說那如果把整個專案改成 Unicode 環境呢？這個我嘗試過了，最終仍以失敗告終。為了這件事我還寫了一份關於「字元編碼與程式設計」的心得。
其他 GUI 框架自己的方案

其實除了微軟的 MFC、WTL 等等之外，Windows 平臺上還有一些其他的 GUI 框架，這些框架可能也覺得現有多語系程式的開發存在許多困難的問題，因此索性也各自提出了自己的多語系方案，比如 Qt 早早就推出了多語系方案，較新版本的 Borland VCL framework 也推出了自己的 ITE 多語系方案，這樣，Windows 上的多語系方案就更凌亂了！

使用這些 GUI 框架多語系方案的好處是這些方案與框架本身最匹配，並且可以無需理會平臺的差異，在不同平臺下都使用同一套做法(如果該框架本身有跨平臺的話)。而缺點就是該方案只適用於該框架，當轉換框架時就要重新來過；或者比如說我今天想要做個 console 工具程式，難道為了多語系的緣故我還要大費周張把 GUI 框架給拉進來嗎？
GNU gettext

最後介紹重頭戲，就是廣泛被用在跨平臺程式的 gettext 方案，這個方案有一些優點：
- 由於使用廣泛且歷史悠久，存在許多現成的工具程式。
- 可以將開發者和翻譯者的工作流程分離，翻譯者無需涉及程式碼和編譯工作。
- 該方案是一個僅僅用於處理多語系文字相關的程式庫和工具集，無涉任何框架，可被使用於任何專案。
- 除了 C/C++ 以外，gettext 還有如 Java、Python、C# 等等多種語言的 bundle，適用範圍挺大。
- 該方案本身無平臺上的強相依性，可被移植使用於任何平臺。
- 該方案本身結構單純，即便在執行時庫的移植或授權上遇到問題，自行實做也很容易。
- 該方案下的語系檔案本身獨立於應用程式之外，可在不動到應用程式的情況下對翻譯資料進行更新、擴充，或加入原本所沒有的語系。
由於 gettext 的執行時庫已被納入 Glibc，也就是說基本上在 Linux 平臺下是原生支援 gettext 環境，連特別連結什麼程式庫的動作都不需要，只要直接使用它就好了，可說是非常方便。由於眾多優點，特別是在跨平臺特性上面的優點，使得大量跨平臺的自由軟體在 Windows 上都還是依循使用 gettext 方案，比如說著名的 LibreOffice。

缺點就是 Windows 並沒有原生支援 gettext，至少需要執行時庫的移植工作； Windows 的 locale name 和 Linux 也不太一樣，需要轉換一下，這些不方便的地方使得 gettext 方案並沒有大量流行在非跨平臺的應用程式上。

以上就是個人對一些多語系方案的見解和觀察，也許有些偏頗或不週全的地方還請多包涵。我本人因為一些緣故需要在 Windows 使用 gettext 方案，目前在移植工作上進行的不太順利，後來一看 MO 檔案的格式超級簡單，索性就自己做了一個簡單的(而且限制比較多的)程式庫解決了我的問題。

gettext 使用指引

雖然主打著介紹和教學的標題，但在本篇裡，我沒有打算描述太多有關於 gettext 的使用細節，只打算做一些比較簡單的介紹，對於較多的操作細節則留待後篇描述。

對於一個使用 gettext 方案處理多語系文字的程式而言，在開發、建置、和發佈等整個過程中，大約會需要面對幾個部份的工作：

如何編寫支援 gettext 的程式碼？請參閱「使用 gettext 方案製做多國語系程式 - 程式編寫」
如何生成翻譯文件並進行翻譯工作？以及翻譯後產生的語系資源檔案要放在哪裡？請參閱「使用 gettext 方案製做多國語系程式 - 製做語系檔」

如何阻止 Windows 10 自動更新

Sun, 06 Oct 2019 21:00:00 +0800

在我先前的文章「Windows 10 十大罪狀(上)」、和「Windows 10 十大罪狀(下)」裡，我細數了許多有關於 Windows 10 的各種惡形惡狀，也許有些人心有戚戚焉、也許有些人適應良好而無感。對於適應良好的人，我只能說恭喜你，你真強大，我望之莫及；而對於那些受到折磨的人，我雖然提供了一些脫離 Windows 10 的方法，但不是每個人都適用。對於那些不論是沒有能力被迫使用 Windows 10 的人，或是因為某些軟體而必須使用 Windows 10 的人，還有沒有辦法提供更多的幫助呢？我想來想去，Windows 10 對於一般人來說最為困擾的大概就是每半年一次的大版本更新了吧！那麼我就提供一些我對於如何對付 Windows 10 大版本更新、或者對付所有的更新的方法。

關於如何阻止 Windows 10 更新的方法，網路上已經流傳很多了，然而最大的問題是他們大多無效。我的看法是，大部份人的做法都是在系統設定上面下手，問題是玩系統你玩得過微軟嗎？系統是人家設計的、程式碼也在他手上，他隨便做點什麼、隨便弄個後門就可以讓你前功盡棄；相對的你所有能夠使用的招式還都是他開出來給你用的你才能用，這樣，你玩得過他嗎？而我提出的方法不一樣，我的方法能夠奏效的機會非常高，其實不是我技術能力特別高還是什麼，我只是站在對的位置來思考策略而已。我不跳進 Windows 和微軟玩 Windows，我是從其他不能受微軟控制的通路上來阻斷系統更新，因為只有站在這樣的位置上才有可能玩贏微軟。

第一招：切斷網路

第一招是切斷網路。電腦若無法連上網，我就不信微軟還能更新！

這招如何阻止 Windows 更新的原理相信不需要多說了吧。這個招式看似慌誕，但已經是我個人所能夠提出的、最不需要技術能力的方法了，雖然這種做法會在現代化的使用過程中帶來許多不便，但執行起來的技術瓶頸低嘛，能力不夠的使用者、或者不想花費太多心力的使用者(比如臨時用一下別人電腦)，就只好將就一下了。

先別說這招可行不可行，我的朋友還真有人就是這麼做的！他家裡的 Windows 10 電腦絕不連上網路，而需要連網的工作都使用公司的電腦、或其他可以上網的舊電腦進行，然後使用隨身碟在不同的電腦之間交換資料。別說什麼不方便，人家我朋友可是作家，他會在家裡和公司寫作，然後靠著一顆隨身碟到處同步資料的喔！

第二招：限制系統磁碟容量

這個原理也很簡單，隨時保持系統磁碟的可用容量在非常低的狀態，這樣更新都下載不下來，就沒辦法安裝了！

首先請先不要緊張，不是所有的磁碟，只要把系統所在的磁碟區可用容量降低就行了，如果你有其它磁碟分割區用來放置其他資料的話，可以不用管它。至於可用容量要多低才行呢？以最新的 Windows 10 version 1903 版來說，在磁碟可用空間小於 32 GB 的情況下是不會進行該大版本更新的；也就是說，只要時常保持可用空間在 30 GB 或 20 GB 以下，就可以不用再被大版本更新給突襲了。雖然一些比較小型的更新可能還是會下載並更新，但至少我們已經把最討厭的大版本更新給擋住了，而且這些小型更新多半可能是安全性更新，就讓它更新吧。那麼如何讓磁碟可用空間變小呢？實際做法有很多種，從最簡單的不斷複製大型垃圾檔案直到塞滿為止，到調整磁碟分割區大小到剛剛好為止等等任君選擇。

縮小磁碟容量以阻擋更新的做法相比直接拔網路的方法副作用更低，電腦依然可以連上網路進行日常的各種操作。由於現在很多人的電腦都會分割出 C、D、E、F、G 等多個磁碟槽來使用，所以下載檔案、一般工作、或是甚至安裝程式等等，只要能夠安裝到別的磁碟分割，理論上是完全不受影響的。若真要說有什麼副作用的話，大概就是在安裝某些大型、且只能安裝於系統磁碟的軟體前，需要刪除一些填塞的垃圾檔案或者調整一下分割區大小了。

第三招：架設 DNS Server 阻斷微軟網址

既然更新程序需要連線微軟的伺服器才能夠執行檢查和下載更新的工作，那如果直接過濾掉任何連往微軟相關網址的連線，不就天下太平了？是的，這個方法是完全可行的，而且副作用最低，使用者可以完全正常的使用電腦、自由的上網、也不需隨時關注調整磁碟容量設定、不會因為系統空間不足而無法下載資料安裝程式等等，唯一的缺點就是這一招是所有提供的招數裡面技術難度最高、最不易完成的做法。

依據網友提供的資料 (Block Access to Windows Update)，只要能夠屏蔽下列網址即可阻斷與系統更新有關的連線：

這項做法的難度在於你不能夠使用 Windows 系統內建的域名表 (C:\WINDOWS\system32\drivers\etc\hosts) 來做，已經有網友證實 Windows 10 會自動忽略對於與 microsoft 網址有關的使用者屏蔽。還記得我說的話嗎？你不能在 Windows 上面使用 Windows 與微軟玩對抗 Windows 的遊戲！因此你需要自行架設 DNS 伺服器，你可以架設一個獨立的伺服器、也可以使用網路閘道器提供的功能(如果你家有閘道器，而且有提供 DNS 相關功能的話)，然後再到你的 Windows 上面設定所使用的 DNS 伺服器，重新指派到你自己的 DNS 伺服器。 DNS 的設定不用太複雜，他只要能夠檢查所有的 domain name 請求，然後回絕黑名單的目的，在把其他的請求直接轉拋到你原本使用的真正 DNS 伺服器即可 (比如說中華電信、Google、或你的 ISP 業者的 DNS 伺服器)。

Windows 10 十大罪狀(下)

Sun, 06 Oct 2019 20:00:30 +0800

接續前篇「Windows 10 十大罪狀(上)」

罪狀三：改個名字呼嚨你 – Fast Boot

從 Windows 8 上市以來，廣告臺詞多了一項：只要 2 秒鐘的超快開機速度。然而這也是讓我非常反感的一點。我並不是說它啟動快是假的，事實上從按下電源到系統備便，正常情況下是真的只要短短幾秒鐘；我反感的是他達成的手段、以及帶來的其他後續影響。

微軟的 Windows 從前一向被人詬病速度慢效率差，而新版 Windows 能開機這麼快，主要關鍵原因在於下列三項：

UEFI 的引入：其實以往開機的一大半時間是被 BIOS 給拖掉的，改用全新的 UEFI 後一下子可以省掉十秒多開機時間。嚴格說起來這部份的加速沒有 Windows 半點功勞，你改用支援 UEFI 的 Windows 7 SP1 64-bits 一樣可以辦到。
SSD 的使用：廣告詞上面的幾秒鐘開機多半都要搭配使用 SSD 才有可能，你可以試試改用 HDD 看看開機會多幾秒？這是 SSD 本身讀取速度較快造成的影響，與 Windows 也無關。
它原來並沒有真的關機：因此它也並不是真的在「開機」，其實實際上是從「休眠」中復原。這是唯一新版 Windows 的設計所造成的啟動加速，也是後面所衍生那麼多問題的根本來源。

看看其它作業系統，有人強調自己開機多快嗎？

Linux 用戶會強調開機多快嗎？以前開機十幾分鐘加快到只要一分鐘的時候會啦，但現在基本沒有在強調了。
OS X 用戶會強調開機多快嗎？好像也沒有，因為 OS X 用戶也許說電腦為什麼要關機？
Android 用戶看看你的手機開機要多久？你會在意嗎？好像大家會回頭問你 Android 幹嘛關機？

那麼為什麼微軟要特別加強開機速度這件事？尤其誇張到要追到只有幾個秒的程度，難道是因為 Windows 用戶一天到晚經常需要開機再開機嗎？我的看法比較偏向陰謀論，微軟其實是為了其他的目的 – 正確來說又是為了綁架你的系統選擇權 – 而做此設計，讓開機速度加快只是它不重要的副作用，正好拿來做為廣告詞而已。

有使用過「休眠」這個功能的人可能會比較了解我接下來的內容。不同於正常的關機，在執行休眠時，系統會將當前的狀態、以及記憶體內的資料備份到硬碟裡，然後關閉電源。這樣下次再啟動系統的時候，作業系統不用重新執行所有的開機初始化工作、不用重新啟動所有的後臺程式，只需把存在硬碟裡的映像檔倒回記憶體，就可以讓整個系統回復到上次休眠前的狀態繼續工作。休眠的好處是可以在短時間內重新喚醒，並且接續上次的工作狀態。而實際使用過休眠功能的人可能還會發現一些有關於它的限制，首先是休眠讓啟動回復更快了，但是進入休眠狀態卻需要花費比正常關機多得多的時間，因為需要把系統狀態和記憶體資料等全部備份起來；再來是雖然大部份的程式都會在喚醒後回到上次工作階段，但仍有部份與硬體驅動程式有關的東西在喚醒後無法正常回復，有些會被重新初始化而無法保存先前的資料，有些可能直到下次重開機之前都處在異常狀態無法工作；而最慘的狀況莫過於「一睡不醒」了，不知是硬體支援問題或什麼緣故，有些電腦進入休眠後便無法再度喚醒，只能整臺重新開機。

在簡介了休眠後，這裡可以告訴大家，當按下 Windows 8 / 10 關機鍵之後其實作業系統並沒有進入關機程序，而是進入了休眠程序。然而微軟顯然並沒有誠實告知用戶這些事，而是很無恥的把那個休眠的功能寫上「關機」字樣！當然 Windows 8 / 10 的關機休眠與我們以往所知的那個休眠並不完全相同，這是微軟重新調整設計過的休眠，大致就是只有將系統核心進行休眠，而捨棄用戶層(user space)的狀態等資料。推測這麼做是因為保存用戶空間狀態需要花費很多時間，並且重新啟動後又回復用戶狀態的話，會讓關機其實沒有真正關機這點太容易被發現。

因此從 Windows 8 開始，微軟營造了一個開機快速的假象，然而其實它並沒有真正的關機，而是讓系統核心從休眠中復原，那當然就快了！有一個流傳小技巧可以佐證這些事，一直到我上一次測試 Windows 10 的時候都還有效：在按住 Shift 按鍵的狀態下點擊「關機」，則系統會進入真正的關機程序。那麼下次開機的時候就是真正的開機了，該花多少時間就是多少時間，您可以拿碼表測測看！ (就我上一次剛好遇到一臺 Windows 10 電腦，又很無聊的測試了一下，大約是一分三十秒左右)

不管是真的開機還是假的開機，反正能加快啟動速度都是好事，又為什麼要說不好呢？原因在於這種做法除了欺騙消費者之外(國外是真的有人在認真討論這算不算詐欺)，還帶來了一些不良影響：

銷售員告訴你啟動只需兩秒，但一定沒告訴你關機要花多少時間！

是的，在經過一些無恥手段之後，開機真的飛速快；那麼關機呢？這不用我再舉例了吧？現在 Windows 10 用戶這麼多，問問你自己， Windows 10 按下關機之後到系統游標開始轉圈圈到主機電源關閉，需要多少時間？特別是在之前的工作中如果你長時間工作或對系統做了許多複雜操作的情況下？ (或是系統需要更新的情況下，不過那是另外一件事)
關機後進行一些變更時容易出錯！

Windows 8 時代曾有網友說過，他在電腦關機之後更換了顯示卡，再次開機後電腦就當掉了！在了解前面的故事後便不難理解這原因很明顯，電腦並沒有關機而只是休眠，那麼醒來之後硬體設備不一樣了，這系統還能正常嗎？到了 Windows 10 時代我好像就沒有再聽說過這樣的情況，可能微軟找了其他方法避開問題吧，比如系統喚醒失敗就重新開機之類的，反正使用者也不會一天到晚變更硬體，偶爾幾次開機變慢也許不會讓太多人感覺到。

除了硬體變更之外還有另一種人也會受到影響，就是在電腦上安裝了雙系統或更多系統的使用者。我看過一些裝了多系統的使用者抱怨(好像都是軟體開發居多)，當他們開機切換到另一個系統時，磁碟往往是被另一個 Windows 10 系統鎖定而無法使用的。當然，能夠進行這樣的抱怨至少還代表他可以重開機進入其他系統，還不算最差的。
難以進行主機板相關設定！

對於硬體設備來說，休眠和關機可能會有所不同。一些比較先進的主機板，比如說支援 ACPI 的主機板，在作業系統要求睡眠的情況下可能會做出特別的反應措施，比如說在下次啟動電源的時候就有可能會略過 BIOS 檢查、或其他某些步驟。然而這造成了一些額外的問題，有些東西可能是在主機板開機階段才有機會進入的，比如說 BIOS/UEFI 設定畫面、或某些多重作業系統的搜尋工作。於是你可以隨便 Google 到一堆人在問 Windows 10 電腦要怎麼修改設定才能進入 BIOS/UEFI 設定畫面的詢問、於是你有機會遇到開機時不會跳出多重系統選擇畫面(被略過了)的問題，而這一切可能並不是主機板的錯，畢竟他們在設計休眠模式的時候，可能沒想到會有作業系統無恥的把休眠當成常態關機在使用吧！

罪狀二：改個名字呼嚨你 – 大版本更新

微軟很喜歡改名字，改名的事蹟多到例舉不完，然而從前的改名只是讓你摸不清他的命名原則罷了；而現在的改名則會暗暗的誘導欺騙你對其意義的理解，例如前面提的「關機」、以及現在提的這個作業系統版本。

一直以來，大家不喜歡微軟每隔幾年就要推出新版 Windows、新版 Office、新版…… 然後強迫大家購買升級。來自廣大使用者諸如「微軟就不能把穩定的 Windows XP 一直維護好就好嗎？」「微軟就不能把經典好用的 Windows 7 一直維護一直加新功能就好嗎？」的呼聲不絕於耳。現在微軟聽見了大家的呼喚，終於說出口：「Windows 10 是最後一個版本的 Windows，此後不會再有新的 Windows 11、Windows 12 等等，微軟會一直維護更新 Windows 10。」然後從此以後皆大歡喜了是嗎？才怪！

實際的情況是：Windows 11、Windows 12、Windows 13…… 依然繼續推出，只是現在它們的名字通通被改成「Windows 10」而已，而它們之間則用所謂「大版本號」來做區別，也就是所謂的 1511 版、1607 版、1703 版、1709 版、1803 版、1809 版、1903 版等等。

有一些現象可以支持這樣的說法，除了微軟親口說出的每年兩次大版本更新之外，有過電腦 DIY 經驗的、稍微熟悉電腦安裝更新與升級工作的人應該都會發現一些奇異的現象。每當 Windows 10 大版本更新過後，就容易出現一些諸如驅動程式異常、系統功能異常、系統功能消失、系統功能或介面大量變化、某些應用程式不再能夠執行、某些程式變得不穩定、週邊設備失效等等。此外，你可能也聽過一些有經驗的人會告訴你：不要直接升級 Windows 10 大版本，直接重新安裝新版本的 Windows 比較好，這樣會比較穩定，問題也會比較少。然後你再思考回想一下，這些現象在以往是不是都是在跨版本更新的時候才會發生的事情？比如說從 Windows XP 直接升級到 Windows 7、或是從 Windows 7 直接升級到 Windows 8 / 10 等等。

結論就是，Windows X 仍然不斷繼續推出，該有的問題一樣少不了；若再搭配自動更新的機制幫你強制更新的話，更是每半年就可以讓你練一下心臟肌肉。

罪狀一：無法關閉的強暴式更新

幾乎不管是什麼人、不論對電腦的了解程度如何、或電腦的用途如何，幾乎所有使用者公認對 Windows 10 最深痛惡絕的第一大罪狀就是自動且強制的更新機制了！

微軟從 Windows 8 開始，修改了系統更新策略，採用滾動式更新，意思就是從此微軟會提供源源不絕的系統更新，讓您的系統隨時保持在最新狀態。這聽起來好像很美好，但最大的問題是微軟並不打算給予使用者任何選擇的自由，而是採用「自動」且「強迫」的方式進行所有的更新，最終演變成為用戶最頭痛且最不想要的功能之首位。

許多 Windows 10 的擁護者會說更新沒什麼不好，「難道你要等中了勒索病毒再來怪微軟為什麼沒有給你更新嗎？」「你用的 Android、iOS 手機也是一天到晚在更新，你有抱怨過嗎？」那麼看來我們就需要分析一下，微軟的更新到底和其他家的更新有什麼不一樣？為什麼大家沒有討厭其他平臺的更新，而只罵微軟的更新？

軟體為什麼要更新？

首先，為什麼軟體需要更新？軟體更新不外乎就是兩個最大的原因：修正已發現的問題(包含改善現有功能)、或增加新功能特性。人類寫出來的軟體，特別是這麼複雜的軟體，本來就不可能完美無暇，有些缺點、有些錯誤、有些漏洞等等都是無法避免的。因此更重要的事情往往是在發現問題後，能不能在合理的時間之內修復，並更新給使用者。觀察現代軟體，幾乎無關任何用途的軟體、或是任何的開發單位，常常都是時不時的在推出新修正版本程式。站在這個著眼點上，維持最新的修正更新對使用者就是最好的，特別是在現代網路發達，各種資安風險後果愈來愈嚴重的現代數位環境下。事實上，我本人平日使用的 Linux 作業系統以及各種開源軟體就三不五時在推送更新，並且更新包的數量相比 Windows 也是多了一個數量級，然而在絕大部分的時候，這些更新並不會對我造成任何困擾。

再說到另一個軟體更新目的：增加新功能。世界總是不斷在進步，人的需求也一直在變化，老舊的軟體即便非常穩定也從未出現過錯誤，也可能因為其所提供之功能漸漸跟不上需求而被拋棄。因此活躍的軟體常常需要發展新的功能以滿足使用者的需求，這種功能式的更新可能會透過軟體直接更新、或要求使用者付費購買升級、或以其他方式提供給使用者。

更新的風險

任何的更新，除了帶來好處以外，當然也會帶來風險。如同軟體的開發，人寫的軟體不完美，那麼人寫的更新也不可能無懈可擊；有沒有可能解決了一個問題，卻反而引入了意料之外的兩三個問題？有沒有可能為了增加一個功能，卻意外的讓原來正常的功能失常？以上當然都有可能會發生。那麼軟體到底更新好還是不更新好，站在不同立場、不同用途的人就會有不同的反應。總是喜歡站在科技最前線、喜歡求新求變的年輕消費者，自然就會主張第一時間裝上所有的更新，偶爾的意外可能無法阻擋他對於新功能的嚮往；而工業機臺、航空飛機等可能就屬最保守的一群，如果沒有必要、如果原來的軟體運作的好好的、如果沒有什麼問題，他們是死都不會更新軟體的；至於網際網路上面的眾多網站伺服器可能介於中間，他們也不喜歡有事沒事更新軟體，原來的系統運作的很流暢、也沒有缺什麼功能，為什麼要更新？萬一更新了造成服務中斷，你要怎麼賠？但對於弱點、漏洞等與安全性有關的更新，他們卻往往要在第一時間裝上，否則會讓有心人士人有趁虛而入的機會。甚至當官方更新製做不及的時候，網站管理員可能還會自己動手把更新的部份修改上去。

你看，一個更新，可以衍生出這麼多的應對。所以一直以來，幾乎所有提供更新的軟體，都會依據自身的規劃，對於更新這件事做出多或少的項目。首先是對更新進行分類，例如安全性更新、功能性更新、新版本軟體等等，其對於前後版本和系統環境相容性、穩定性保證等等都有大小不一的規範，由使用者依據自身的需要自行選擇需要的項目。而那種新增了很多功能、修改提升了很多軟體特性的大版本更新等，則甚至可能會要求使用者付費購買才能夠升級。

Windows 10 不分類更新

那麼在經過對於「軟體更新」這件事的一番解釋之後，看官應該能夠發現 Windows 10 更新的第一個錯就是沒有對更新進行良好的分類。其實這不是什麼新功能，在 Windows 7 上面，微軟就對更新分成了「重要更新」和「建議更新」兩類，其中的重要更新在預設的情況下為已選取，依據使用者的設定甚至可能會自動進行更新；而建議更新的項目則只有在使用者手動選取的情況下才會進行更新。然而到了 Windows 8 之後，這些更新全部攪在一起不再分類，事實上也不提供什麼更新項目選擇，等於是更新來了後，不管大小、不管後果全部都要你裝上。

Windows 10 沒有選擇更新項目的權利

Windows 10 在更新的部份不給使用者選擇。你沒辦法選擇要的或不要的更新，事實上在微軟設計的、使用正常配置面板的情況下，你不能夠拒絕任何更新，只要更新來了你就得裝。這件事情對於喜新厭舊的年輕消費者來說可能不是什麼問題，但對於那些擁有任何程度「安定性」要求的用途上，Windows 10 足以讓電腦維護技術人員不會沒有工作。

Windows 10 的強暴式更新

Windows 10 會全自動的在他想要的時候進行更新工作，而不是使用者希望的時候。我記得在 Windows 7 和 Windows XP 的時代，就是那個我們對於更新這件事還有比較正常選擇的時代，即使把更新全部設定為全自動(比較省事)，他也會問你希望 Windows 在什麼時間進行更新工作？記得預設時間是當地時間凌晨三點，當然使用者可以變更為任何不被打擾的時間。而 Windows 8 開始完全捨棄了這些，微軟對於自己的 AI 程序擁有最大的信心，系統可能會在任何他覺得適合的時刻開始更新工作，而且按照慣例，使用者沒有任何選擇的權利。於是你就會在網路論壇上看到各種令當事人咒罵比爾蓋茲祖宗十八代的案例，什麼畫家畫了多久的作品一早醒來全不見了；什麼直播到一半、遊戲到一半、還是新聞播到一半的時候，系統開始自動更新；什麼上班工作到一半，系統開始更新，直接讓你原地放假；什麼膝電要關機的時候開始更新，讓你出不了門，或者重要展演要開始的時候，膝電一打開就看到他正在更新而且無法停止；甚至我曾耳聞有同事把膝電休眠後放在背包裡，你猜怎麼著？它自動被喚醒然後開始更新！等這同事要把膝電拿出來用的時候發現電池已經沒電，而且電腦好像已經燒壞了，出現焦味(背包內散熱不良)。

不是只有外顯可見的更新工作對使用者產生影響，在真正的更新工作開始之前，系統就需要時常的檢查微軟方面的伺服器是否存在新的更新、運算檢查當前的電腦是否適配這些更新、然後再偷偷的下載這些更新包，最後才是在最適當的時間發動主要的更新工作。因此，早在被顯而易見的更新工作打斷之前，使用者就能夠時常感覺到電腦變慢變頓。當下載工作開始時，網路頻寬被佔用導致網速突然降低，除了那些正在網路即時遊戲上激烈交戰的玩家可能會突然失利以外，也會讓使用了比較昂貴上網服務的用戶有機會收到上漲的網路服務費。此外下載下來的更新檔案大小從數 MB 到數 GB 都有可能，對於使用了低容量 SSD 做為系統磁碟的人更是苦不堪言。

看到這裡，不難明白為什麼許多人把 Windows 10 的更新稱為「強暴式更新」了吧！

Windows 10 更新工程浩大且令人膽顫心驚

嚴格說起來，這不能歸咎於 Windows 10，因為 Windows 各系列的更新從來都是工程浩大。眾所週知，Windows 的更新除了更新包龐大之外，更新工作執行起來更是耗時費力，動輒動用數十分鐘，有時甚至需要數小時至一天才能完成，其中可能需要重新開機數次。像我使用的 Linux 常常也會有更新，我很多時候也會利用關機之前的時間執行更新，遇到大軟體的更新或核心更新了不起也只花費兩三分鐘即完成，對我沒有什麼困擾。然而 Windows 用戶為什麼關機前看到系統進入更新畫面就會惱火？因為這可能代表著接下來需要等待五分鐘、十分鐘，也有可能半小時或一小時，甚至更久。你說關機就離開讓它慢慢更新就好，那如果人家是膝電要帶走的呢？如果公司週末下班要關電源，就等你的電腦還沒關機完呢？何況 Windows 10 不只是關機會更新，他開機時也可能會更新，使用到一半也可能會開始更新！說起來吊詭，從 Windows 8 以來主打的兩秒鐘開機特性，就被這個三不五時會遇上的開關機更新給破壞了。

只是更新花的時減久一點還不至於怨恨那麼重，還要再加上它隨時可能在你意想不到的時間開始更新，才加深了用戶的怒氣。只是這樣也還好，若再加上偶爾會碰到更新竟然失敗的情況，那就更讓人想砸鍋。網路稍微多搜尋一下不難發現，許多更新到一半卡死在多少百分比的案例、突然變黑再也開不起來的案例。最慘的莫過於系統發現更新失敗後自動嘗試退回更新，然後又自動且無法拒絕的再次更新，然後再回退、然後再更新，如此反覆不止！

Android 和 iOS 的更新沒有比較少，但極少會給使用者帶來麻煩。仔細探索會發現，使用者們常常期待新的更新會帶來哪些意想不到的功能；而對於 Windows，期待更新帶來新體驗的人好像非常少，更多的似乎是猜測等待這次更新又會帶來什麼新災害？ Windows 10 的更新總是驚嚇大於驚喜，也許這點也是其與其他系統平臺更新功能的最大不同之一吧。

Windows 10 的病毒式更新保護

大概是微軟覺得 Windows 10 是整個微軟事業裡面至關重要的戰略要地吧，所以總是竭盡所能的保護作業系統上的更新機制，不讓任何的駭客們破壞；至於使用者的意圖？可能當使用者想要破壞自動更新機制的時候就不再是微軟的使用者了，而是微軟眼中的駭客，所以一樣要當駭客來對付！

Windows 10 更新所帶來的這樣那樣的問題實在是太多太討厭，嚴重到讓使用者覺得關閉任何的更新所帶來的資安風險甚至低於更新系統所帶來的災害風險。但微軟並沒有提供在正常設定管道關閉或調整有關更新的項目，於是上網隨便搜尋就會發現大家似乎都對於如何關閉 Windows 10 的更新這件事非常感興趣。當然，做為微軟最重要商業策略之一的更新，他當然不會坐以待斃的讓使用者破壞它，於是雙方展開了一場互相駭客的戰爭。然而，微軟做為作業系統的開發商和發行商，你能比微軟更了解 Windows 嗎？於是這場戰爭從一開始就不平衡的往微軟方面傾斜。

網路上流傳各種關閉 Windows 10 更新的方法，包括試圖關閉更新服務，結果發現這個更新服務似乎會被偷偷的自動啟用；修改註冊機碼、設定群組原則、設置佔位用的假執行檔和假程式庫檔等等等等，當中有一些暫時有效，但一定時日後又發現更新程序竟然復活起來繼續運作！甚至有人設定了 DNS 規則，屏蔽掉與 Microsoft 有關的網址，結果發現 Windows 竟然會刻意忽略對 Microsoft 相關網址的引導行為。這整個過程就如同駭客電影一般，而最後，Windows 10 的更新程序總是會用各種花式方法重新復活，然後繼續困擾使用者。微軟對於 Windows 10 無微不至的更新保護機制，已經讓 Windows Update 本身形同病毒軟體，並且截至目前為止，還未見有什麼有效的方式可以對付這隻史上最強大的病毒。

Windows 10 大版本更新

我們前面介紹過改名呼嚨你之大版本更新，這裡也介紹了病毒強暴式自動更新，那有沒有想過當他們兩個結合在一起之後又會形成怎麼樣一個毀天滅地的災難？因為 Windows 10 更新不分類的結果，這種在以往會改個名字叫你掏錢買的大版本更新，現在會隨時像普通更新一樣免費裝給你，再加上自動更新以及後臺偷偷更新的機制，你不能拒絕、也無法得知什麼時候會開始進行這種翻天覆地的更新行為。

大版本更新並不是不好，否則人們就不會從 Windows 3.x 升級到 Windows 95/98、再升級到 Windows XP、再升級到 Windows Vista/7、然後再升級到 Windows 8/10。大版本更新好或不好、需要或不需要見仁見智，然而搭上了全自動更新模式在你最意想不到的時候進行升級，這樣就不好了！

感謝微軟現在免費讓我們升級新的 Windows 10 大版本，但是大版本的升級實在太令人膽顫心驚。每當大版本升級後，幾乎都可以見到網傳一片哀嚎，有的人喇叭沒聲音了、有的人印表機不能用了、有的人網路不能上了、有的人某個特別的軟體就不能用了、而有的人連開機都開不起來了！有的時候新版本會把設定項目大搬家，搞得大家一陣子無所適從。你說新版本比舊版本好，你說舊版本以後要慢慢被淘汰了，我都同意，但是你就不能讓我在自己覺得最適合的時候，什麼備份還是什麼的都準備好的時候，我自己來升級不行嗎？就是像我們以往升級作業系統那樣。也許我比較喜歡重新安裝新版的作業系統，而不是直接升級上來呢。現在搞得大家每半年(微軟的大版本更新大約每半年一次)就得強迫玩一次俄羅斯輪盤，各個公司單位裡的資訊人員每半年就要上上下下折騰一次，每半年就會有大量小型商家叫修電腦，每半年就會有同事一聲哀嚎後立刻賺得在公司原地休假不用工作的福利。

然而我覺得最嚴重的是自動大版本更新帶來的相容性問題。許多特殊用途的電腦，比如說工業機臺、ERP 等特殊客製系統伺服器、或者其他運作著特別開發的軟體程式的電腦等等，這些程式往往是針對特定的作業系統版本開發的，要不就是只在特定的作業系統版本測試過，那有沒有可能 Windows 10 一更新就造成這些軟體無法正常工作？當然是有可能。這些軟體與一般消費終端用戶平常使用的軟體不同，軟體開發公司不見得會一直持續推出新版本 (甚至有些後來就倒閉了)。有些比較有規模有能力的開發商會與時據進不斷維護，但需要用戶掏錢更新。問題是你看這些客製化的軟體動輒上百萬，你覺得用戶會認為應該隨時保持在時代前線不斷更新 Windows 10，然後不斷花錢重買上百萬的軟體系統嗎？他一定會告訴你原來的東西用的好好的，沒有需要為什麼一定要更新不可？問題是，在 Windows 10 的時代，只要你的電腦一插上網路，基本是沒辦法阻止它更新的！

工廠、企業那些離我們個人也許有些遙遠，那就在來看看無限制大版本更新對個人用戶會有什麼影響？軟體總是不斷推陳出新，這我們都知道，但大家硬體設備難道也是常常丟舊的買新的嗎？個人電腦使用數年之後，運作當代的軟體就會愈來愈吃力，但是你可以選擇不要讓老電腦運作新系統啊！比如說有一臺十幾年前的電腦，上面運作著 Windows XP 系統，但是整體運作仍然良好，那救繼續用下去沒有任何問題。也許慢慢有些現代軟體不再支援 Windows XP，所以又買了新的電腦安裝 Windows 7，至於原來那臺依然安穩的繼續用下去，完全沒有問題。我可以平常使用新電腦，遇到一些老程式、老遊戲、或者 IE6 限定的政府網頁，我就用那臺舊電腦。這臺舊電腦可以就這麼一直用下去，直到有一天它完全壞掉為止、或者我不再使用而把它送人為止。但是，在 Windows 10 的時代，上面的情境是不可能在發生了！老電腦的系統會不斷的、自動的被更新，也許三五年吧，它可能就會卡的不像話、或者好多硬體功能不再作用。最後會逼的你必須把這些設備淘汰，因為你沒有辦法在上面運作舊版本的 Windows 10，即使你想辦法安裝舊的 Windows 10，只要一插上網路又前功盡棄。也就是說，Windows 10 的時代會造成另一個現象：硬體設備被強迫在約三五年間被拋棄，即便它還並未真正走到生命的終點；而使用者被迫三五年就需要購買新的電腦設備。

我能夠免去 Windows 10 的危害嗎？論應對對策

既然 Windows 10 這麼十惡不赦，可是現在整個 3C 商場上全都是 Windows 10，如果真的不喜歡 Windows 10 的話，那麼我們能有什麼對策呢？

對於一般使用者

我知道很多普通用戶恨死了 Windows 10，他們本不需要了解電腦原理，只求能夠安穩的使用，那麼有沒有什麼好的對策可以讓大家免於 Windows 10 的蹂躪呢？很不幸的，對於一般的廣大使用者群來說，你們沒有任何有效的方法可以逃避 Windows 10！

如果你耐心的閱讀完了前面的論述，就會明白微軟在自身策略上、聯盟策略上、市場環境上、以及技術壁壘上用盡了方法阻止你不用 Windows 10，如果你本身又沒有一點點電腦知識和技術能力的話，基本上只能微軟叫你做什麼，你就只能做什麼，然後努力適應他給你的一切。就像很多 Windows 10 擁護者說的話一樣：如果你覺得微軟的科技產品難用，那絕對不是因為微軟不會設計，只是因為你跟不上時代，請調整自己的腳步、改變自己的習慣、努力說服自己微軟的一切都是好的。 (謎之音：你看，被強姦的感覺多爽啊！)

對於進階使用者

對於擁有一定程度的電腦相關知識，懂得從 BIOS 設定到格式化再安裝作業系統、到可以自行安裝驅動程式並自己調校電腦的使用者來說，你們還有很多方法可以在新電腦上安裝 Windows 7 作業系統。以目前的技術壁壘來說，只要你能搞定 Windows 7 安裝光碟來源、Secure Boot、 USB3 驅動、以及其他硬體設備驅動、並搭配使用獨立顯示卡的話，你還是可以繼續使用 Windows 7 作業系統。

平心而論，如果只看 Windows 家族的話，那麼 Windows 7 就是個人評價有史以來最好也最經典的作業系統！至於其他傳言說什麼 Windows 7 是過時產品、即將不支援、即將被淘汰等等，大部份都是個別擁護者帶風向的言論，可以暫時不去理會。再怎麼說，Windows 7 至今還沒超過原廠支援的期限(2020-01-14)，現在談過時會不會還太早了？

不過那些擁護者說的也沒錯，雖然現在確實還是可以使用一些技術手段繼續留住 Windows 7；但預料不會太久的時間，新的技術壁壘會愈來愈難跨過，即便跨過了，也會愈來愈難使用新軟體和新週邊設備。終究，你還是必須要去面對 Windows 10 的問題。

對於高階使用者

難道我們真的沒有任何方法可以逃避 Windows 10 了嗎？ Windows 10 這麼爛、Windows 7/XP 等又即將過時，我們還能怎麼辦？答案是：為什麼你非要用 Windows 不可？如果你把眼光放遠一點就會發現解決問題的方式並沒有那麼複雜，不要用 Windows 就好了！

所以你會看到有一些人開始改用 Apple 電腦、有一些更高級的人改用 Linux 系統、還有一些更莫測高深的人會改用 BSD 等我們可能都沒聽過的系統。我們這些人早就已經脫離 Windows 的泥潭，現在才能夠笑看還陷在 Windows 爛泥裡面的人。

當然，我也知道脫離 Windows 談何容易？新的系統使用方式、習慣、相容的程式等等等等全部需要重新學習重新適應。幾十年的習慣、幾十年的知識，豈是這麼容易說拋棄就拋棄？所以真正能夠脫離 Windows 的人要不就是真正的高端份子、要不就是身處在高端份子環境裡被逼迫之下才能辦到。我也是因為深深的了解這點，所以前面才會說出對於普通使用者基本只能受人宰割的話語。但是若任何人願意鼓起勇氣跳出窗戶、保持毅力勇往直前，那麼在一段陣痛期過後，你會發現海闊天空，也會體悟「科技是用來服務人而使人更方便的，而不是人應該要去遷就爛設計」這句話。

Windows 10 十大罪狀(上)

Sun, 06 Oct 2019 20:00:00 +0800

這一陣子好像又看到不少 Windows 10 更新的災情，讓我感慨萬千！畢竟這麼大一個公司，聚集了這麼多頂尖人才，卻總能這麼一直產出軟體炸彈也真是不容易啊。本來我一直不了解幾十年來大家一邊痛罵微軟，一邊又死抱著微軟不放是什麼心態？本來對於別人用微軟產品頻頻踩坑我多半也是當笑話在看。但前一陣子和電腦工作室討論欲購買的新電腦規格時，老闆兼資深工程師竟然推薦我使用 Windows 10，說這是(微軟的)趨勢，Windows 7、XP 已經漸漸不支援不能用了。我立刻就不服氣，Windows 10 可是有史以來我用過最爛的作業系統，除了使用上各種難用、緩慢、卡死、找不到東西外還有很多別的問題，於是當場表明我不用垃圾系統。

看到這裡，應該也能明白我對 Windows 10 怨念極深，這是確實的。為了向那些不明白 Windows 10 到底哪裡不好的人解釋，這裡我就要整理邏列對於 Windows 10 的十個大惡狀！

提要

網路上對於 Windows 10 的評價大致可分為比較極端的兩派：一派大力抨擊 Windows 10 超級難用或超級惡劣，這一派的人裡面可能有不少實際踩過坑、吃過鱉；另一派則擁護 Windows 10，甚至覺得它是有史以來最好的系統，他們可能剛好自己的電腦適配目前的 Windows 10，從沒遇過另一派所描述的問題，本身也非常的適應微軟所設計的操作動線與美感。而擁護派的人常常攻擊反對派的人，說他們是因為懶惰、老化、不思進取，才會無法適應新鮮的尖端設計。

那麼為了說服大家我的感受和論點具有價值，除了後面的觀察歸納分析以外，我想有必要交代一下個人的經歷背景，好了解我不是因為固守舊物、頭腦僵化才反對 Windows 10；相反的，我的反對是在仔細的觀察體驗後才得出的結論。

個人從大約 8 歲開始使用電腦，經歷過不同世代的作業系統，在微軟體系下的就用過： DOS、Windows 95/98/ME、Windows XP、Windows 7、和 Windows 10，因此可以自認對於歷代 Windows 作業系統都有比較完整的體驗。除了微軟體系外，我還因為接案需求短暫使用過 Apple OS X，以及自學入門 Linux (Desktop、Server、Embedded 都有)，因此在廣域的作業系統使用體驗上也自認有一定的比較能力。至少，我不使用 Windows 10 不是因為僵化固守；事實上正是因為我接納並學習新事務，別說 Windows 10 了，我拋棄了整個 Windows 和 MS 系列產品，目前在 GNU Linux 和自由軟體體系工作生活愉快！

就算不說太多私人因素，只從客觀資料上來看， Windows 10 在 2015 年上市，市佔花了一年到了 2016 才超越 Windows XP，到了 2019 年初才超越 Windows 7，並且這還是在各種強迫中獎的手段逼迫下才達成的數據。在微軟各種手段之下，大量使用者仍找尋各種方法死守在舊的系統上，我想這些現象都已經足夠說明 Windows 10 不只沒有那麼美好，甚至可能是爛的可以！

對於有些在 Windows 10 上面吃過土的人可能會有點小小的失望，因為你們感覺被坑的原因沒有被列出來。這裡我就要先小小說明一下，因為標題的緣故，我需要精選出個人認為最嚴重的十個缺陷；同時那些容易被修復、或在可預見的未來內有機會被改善的問題，都不在評論範圍之內，也就是說，我儘量只提那些根本上的缺失或其他設計上的重大缺失。

罪狀十：不讓你用舊的 Windows

微軟大力的推銷自己的新產品 Windows 10，並且也希望全世界的人都來用它，說實在這是無可厚非的事，哪個人做產品不是這樣呢？然而因為 Windows 10 (包含之前的 Windows 8 / 8.1)做的太爛沒人想要，於是微軟便無所不用其極的強迫全世界的人來使用他們的新產品。

雖然嚴格說起來這不能算是 Windows 10 本身的錯誤，但因政策實在影響消費者太多，而且所有的策略都與 Windows 10 這個名字有關，因此我估且把它排在第十名。

首先他停止販售舊產品 – Windows 7，不管是零售還是 OEM，這樣新的用戶就算不想買 Windows 10 也沒辦法。不過這倒不是什麼新招式，一直以來微軟靠著停售舊產品來推廣新產品的策略已經實行很久了。

但是這麼做只能影響新購戶，對於那些原本就已經擁有並已經使用舊版本 Windows 的人構不成誘因。於是微軟推出了臭名招彰的策略 – 讓舊版本系統自動更新升級成 Windows 10。而且為了防止想要升級系統的你一不小心按錯按鈕而沒有升級到，因此好心的移除了拒絕升級的按鈕！後來他們大概發現有些人可能一時來不及閱讀訊息文字，就把更新升級的對話框當廣告框給關閉了，於是他們把關閉升級視窗的那個叉按鈕等同視為用戶同意進行更新，記得這個舉動一時之間讓全世界的 Windows 用戶都興奮活跳了起來！

還有不少新購電腦的用戶不會購買作業系統，他們可能從前已經買過作業系統，或者使用公司、學校的大量授權版本，或者安裝盜版系統。不論哪一種，都讓停售舊產品的招數對他們無效，若他們能夠躲過自動升級的話，就會變成難以對付的舊版釘子戶。除了利用 UEFI Secure Boot 來圍堵其他作業系統之餘還順便防堵舊版本 Windows 之外，現在還聯合 CPU 廠商來撲殺舊系統用戶。以 Intel 來說，大約從 2016 的 Skylake 開始便不再支援 Windows 7。我明白舊的產品總是慢慢的會與時代脫節，支援成本會愈來愈高，最終導致大家不願意再支援；但對於一個未超過十年且仍在大量使用的產品，連微軟自己對 Windows 7 的支援都要到 2020 才終止，你 Intel 這麼趕急是為了什麼呢？看來這 WinTel 的名號可不是隨便說說的呢！

罪狀九：又醜又爛的 Metro UI

從 Windows 8 開始，微軟引入了全新的 Metro UI，這套系統就一直延續到了 Windows 10。

從我第一天看到廣告上的 Windows 8 的時候，當下第一個想法是微軟是不是把他們的美術設計全部辭掉然後改用了超便宜工讀生來替補？看看那個介面、那個配色、那個長相，竟然還有些人說這樣比較漂亮比較美觀的，我都懷疑到底是得了斯德哥爾摩症候群還是天生美感缺乏？

我記得以前，新的 Windows 一推出總是會讓我耳目一新心生嚮往。曾經好幾年的時間，我的電腦因為一些現實考量而維持使用 Windows 98 (主要是配備規格不足、加上 SP2 以前的 Windows XP 問題很多)，但仍然到處找有沒有讓 Windows 98 貼上 XP 貼圖皮膚的套件。曾經一邊用著 Windows XP 一邊想著哪天換新電腦的時候換成漂亮華麗的 Windows 7，尤其那個毛玻璃特效讓我好喜歡。然而到了 Windows 8 (8 / 8.1 / 10) 卻讓我完完全全沒有這種想法，心理立刻冒出的感覺反而是：天啊，這什麼醜死人的東西？我上次見到這種畫面風格的東西好像是…… 喔對，Windows 3.1！

暫且就先撇開美不美這種比較主觀的觀點，來看看其他比較實用的方面。微軟因為他的商業策略考量，需要一個統一桌面和行動裝置的使用者介面，這點我了解，但是他們顯然沒有做好不同裝置下的介面統一。在桌面系統上，傳統 UI 介面和 Metro UI 介面各放一套，互相擾亂使用者。你可以說這是為了兼容那些老舊的程式，他們必須在傳統的 Windows UI 環境下才能正常運作，但是所導致的使用干擾卻是無法否認的事實，所有的東西都要分兩套 – 傳統桌面版和 Metro UI 版，連桌面自己也是。

隨便 Google 就會看到很多案例，其中經典的大概就是設定面板也分成兩套，不只長相不一樣，連內含的設定項目也不一樣，弄的使用者都不知道要改個東西要去哪裡找？連微軟自己的 Edge 瀏覽器也有兩種不同版本，弄得大家暈頭轉向。以上還是有資源把各種東西搞兩套的廠商，而若遇到一些比較不全面設計的軟體、或者是已經改不動的老軟體，那就會變成只能在某一個模式下使用它。然而我們用電腦當然不是只用一套軟體，因此有些軟體只能在傳統桌面下運作、有些軟體只能在 Metro UI 下運作，而且彼此不一定能良好的互相支援，例如一些舊的輸入法。

如果這樣不夠讓人暈，那就來看看更暈的。 Metro UI 的那個首頁上面(叫它「首頁」是因為我不知道它的正式名稱叫什麼)，各種常用還是釘選的應用程式會顯示某些內容畫面，並且還是動態變化、不斷切換的。這東西是好是壞也許不同的人有不同的說法，但隨便 Google 就能找到一堆人在罵這個東西，我想就足夠說明它確實擾亂了一般使用者的操作流暢度。怎麼說呢？除非是第一次熟悉某個裝置，否則我們操作電腦的過程中仔細想想其實存在不少慣性。比如說今天你想要打開 Sykpe，你會很認真的按下開始程式集，然後比對哪裡寫著「Skype」，然後再按出延伸選單(若有的話)，再點擊執行檔嗎？不是吧？通常我們應該只會一眼飄一下有一個藍色圓圓的、中間有白色字樣的那個圖在哪裡對吧？甚至我們並不會整個列表搜尋，因為真的常用的程式，選單點開以後它會出現在什麼位置我們都已經知道了，眼光就會直接往那邊飄。除非安裝、移除、或變更了一些程式，導致開始功能表的排列有異，這時我們開啟軟體才會稍微遲疑一點。好的現在可好，這些圖示畫面變來變去飄來飄去，簡直就是在訓練撲克牌翻牌遊戲一樣！如果說微軟去除一些如毛玻璃等 3D 特效而帶入扁平化是為了解決行動裝置運算能力不足的問題的話，那麼讓這些畫面動來動去又是為了什麼？

罪狀八：爛輸入法機制

當然也是為了因應行動裝置，微軟從 Windows 8 開始，改用了新的 TSF 輸入法系統，這直接導致已經流通的使用 IME 輸入法系統的舊式輸入法如「無蝦米輸入法」等無法再使用，雖然之後好像又增加了對 IME 輸入法的相容性，但新輸入法系統在其他方面造成的不良影響仍舊無法挽回。

其實輸入法系統的革新不見得是壞事，只要仍在發展維護的輸入法系統，都可以在一個可期待的時間內得到適用新輸入法系統的更新；實際上新輸入法系統最大的殺傷力不在相容性上面，而在於相關切換按鍵的設計。不知為什麼，微軟大幅的變更了輸入法的切換按鍵與按鍵組合，直接無視大家十幾年來的習慣。

然而這還不是最慘的，新的系統還引入了新的制度，即「語言」與「輸入法」。要切換到某個輸入法，首先要先切換語言環境到該輸入法所屬的語言下，然後再切換到你要的輸入法。我至今還想不明白，就一個輸入法的切換要搞得這麼複雜幹什麼？一個人是能夠同時熟悉幾種語言？是到底同時需要多少不同語系的輸入法？我慶幸我不用在微軟的輸入法爛泥裡面打轉，雖然我使用的 GCIN 輸入法系統內含了不下二十種不同的輸入法，但不同輸入法之間的切換也沒有搞得這麼複雜！

如果你覺得輸入法的坑只有這樣，那你就錯了！輸入法的切換不是只有層級複雜，也不是只有按鍵與以往不同，現在「Shift」按鍵也可以用來切換中英輸入模式。問題是，單按 Shift 按鍵早已經被很多軟體設定為各種特殊用途了，比如說輸入大寫字母、比如說遊戲裡的奔跑、比如說影像處理軟體的圈選模式。那系統如何正確的判斷使用者按下 Shift 時的意圖呢？依據網路上的意見來看，顯然是不能。所以你應該很容易在一些需要比較複雜的按鍵操作的軟體裡，體驗到輸入法亂跳的感覺。

如果你覺得這樣已經夠慘，那你又錯了！從 Windows 8 開始，系統開機預設的輸入法是當地語系的輸入法，說白話一點，以大部份的臺灣用戶來說，就是微軟的注音或新注音輸入法。可能微軟覺得這樣的設定比較本地化吧，然而大部份的人應該都早就習慣預設英文輸入，需要輸入中文時才切換輸入法。就算習慣可以重新調整適應好了，問題是說實在的，除了打字以外，在大部份的電腦操作中其實最需要的是英文字母鍵入的功能，比如說各種系統快捷鍵、軟體快捷鍵、在開始功能表搜尋應用程式、打網址、打帳號密碼等，於是我們往往需要不時的把注音輸入法切換為英文輸入。如果只是一開機一登入的預設輸入法是中文就算了，只是剛登入的時候要切換一下而已；然而微軟的做法卻是各個應用程式、各個視窗對於輸入法都是獨立的個體，因此實際上你開新的程式、開新的視窗、或者切換視窗以後，都要不厭其煩的切換一下輸入法！甚至因為可能某些軟體狀態沒寫好的緣故，你在同一個視窗的不同輸入框之間轉換以後，輸入法又會跳來跳去。往好處想就是，Windows 10 用順了以後，你的腦袋應該會更敏銳，真可謂用心良苦啊！

罪狀七：不能良好支援國際通用 Unicode 格式與通用的純文字文件格式

我承認這個標題下的有些饒口，其實就是 Windows 對於 UTF-8 衍生的各種問題仍然一點解決的跡象都沒有。有看過我以前文章的人大概知道我是個軟體開發人員，常常與編碼、純文字為伍，因此對於微軟在這方面的坑深感痛惡；至於一般比較少接觸到 Unicode 與純文字文件的人可能就比較難感受到它的惡了，直到你遇到亂碼文件之前！

嚴格說起來這其實也不能算是 Windows 10 的錯，因為 Windows 自古以來都有同樣的問題。但我記得當時 Windows 10 剛發佈的時候，我就立刻去微軟網站下載了 Windows 10 光碟來試玩，第一次開機就立刻去試的第一個東西，就是看看新的作業系統是不是解決了編碼與格式的問題？解果顯然是沒有！

首先是系統語系裡面仍然沒有 UTF-8 的支援，看來微軟還是不樂意 UTF-8 在 Windows 上流行。再來是系統預載的記事本仍然預設存檔為舊式本地格式編碼，而不是任何一種 Unicode 編碼，這說明了 Windows 10 仍然會努力不卸的一直製造亂碼文件；而就算手動選擇存檔格式，依舊仍然沒有辦法存檔為 No-BOM UTF-8！

既然都提到了純文字文件，那就順便再提這個換行格式。到了 Windows 10，微軟的記事本依然只支援 CR LF 換行，然後讀到其他的換行格式就會整個排版錯亂。實在是難以想像，其他的幾乎任何一款文字編輯器或檢視器都已經可以正確辨識與排版各種換行符了， OS X 甚至都捨棄了他傳統的 CR 格式改為使用 LF 格式，只有偉大的微軟對此仍舊沒辦法，我想就算我用「垃圾」這個形容詞來形容微軟的產品，一點都不為過！

罪狀六：對傳統機械式硬碟存取效率太差

我想現在在使用 Windows、特別是 Windows 10 的廣大使用者應該都知道一件事：電腦一定要裝固態硬碟(SSD)，至少系統碟要使用固態硬碟。問為什麼？因為 SSD 讓電腦加速很多，因為傳統硬碟(HDD)速度太慢！

如果我告訴你一般電腦其實根本沒有必要使用 SSD 呢？如果我告訴你電腦需要 SSD 其實是因為 Windows 10 做太爛呢？ SSD 價錢那麼貴、容量那麼小、可靠性和耐操性又不如傳統 HDD，為什麼我好好的 HDD 不用然後要去買 SSD？我這麼告訴你吧，我家裡的和公司的好幾臺電腦都只使用 HDD，速度並沒有比較慢。我曾在桌機上使用過 SSD，是真的有加速，但並不如一般 Windows 使用者描述的像是從烏龜變老鷹的感覺。為什麼？因為我的電腦在使用 HDD 的情況下就已經像飛一樣快了，以至和 SSD 之間並沒有太大的落差感，這一切必須要感謝全世界的 Linux 開發者在檔案系統設計、快取機制、和磁碟讀寫排程器上的付出！然而我並不是說 SSD 完全不好，事實上我的膝電幾乎都只裝配了 SSD，但不是為了它的速度，而是 SSD 除了耐振動外還更加省電，可以讓我的電池撐得比較久的緣故。

其實一般來說，作業系統的檔案系統模組本來多少都會針對硬碟做一些最佳化設計。回到 Windows 上，從前沒有 SSD 的時候你覺得電腦慢了嗎？會卡卡的嗎？再進一步問，不同 Windows 版本的用戶裡，誰最推崇 SSD？就我的觀察，一般是 Windows 10 的使用者對於 HDD 和 SSD 之間的差異體驗最為明顯，告訴你用 HDD 會太慢、會卡的多半也是他們，而 Windows 7 以下的使用者就比較沒有那種非換 SSD 不可的念頭。所以真像其實是：Windows 10 對機械式 HDD 的支援太差！這不是我亂講，有一些現象可以佐證這個觀點，網路上可以搜尋到許多從 Windows 7 升級到 Windows 10 的經驗，如果他們原本使用 HDD 的話，幾乎會一致的體驗到系統反應變慢、偶而會卡、硬碟時常嘎嘎響等問題。你看在這些案例下所有變因都不變，同樣一臺電腦、同樣的配備，唯一的差別就是作業系統不同而已，還不夠說明 Windows 10 硬碟讀寫策略的問題嗎？我都合理懷疑微軟為了產業聯盟而故意這樣子做，好促進 SSD 的銷售！

罪狀五：不尊重用戶隱私權

Windows 10 變更、加入了很多新的隱私策略，讓他的使用者幾乎沒有隱私可言。不知道為什麼？歐美人士對於隱私這件事非常在意，反彈也很大，反而東亞地區的人好像覺得被人偷看到全部看光光都無感？

從以前大家就口耳相傳，微軟會偷偷上傳作業系統的正版驗證資料，嚇得好多人裝機完的第一個步驟除了下載其它瀏覽器之外，大概就是關閉作業系統更新。到了 Windows 10 的時代更變本加厲，有大量不知名的後臺程序時不時不知道在運算什麼東西，如果你沒有配備 SSD 的話，那麼它們也是導致你的電腦變慢變卡的元兇之一。此外，這些為數不少的背景程序還經常會默默的上傳不知道什麼東西，據信其中包含了各種用戶個人訊息、裝置資訊、以及用戶行為記錄等 (因為 Windows 不是一個開放的系統，所以基本沒有人可以確定 Windows 確實的行為是什麼，一直以來只能透過一些外顯跡象進行推測判斷)，而且據說這些行為在您安裝 Windows 時的授權條款裡面都有提到，相信大家都同意了吧？！ (這裡用據說這詞是因為我也從沒有仔細閱讀過該條款，反正我現在又不用)

但令我最為震驚的其實是：Windows 10 裡面充斥著廣告！沒錯，你能夠想像嗎？一個付費購買的、知名大型廠商發行的、在電腦系統中屬於基礎元件的作業系統，原生充滿了廣告！

不過也不用太傷心，當中有一部份的隱私相關設定是有被微軟開放出來的，也就是使用者可以透過變更系統設定來關閉或禁止部份的隱私相關行為。需要注意的是，這些設定預設是全部打開的，換句話說就是，如果你是普通的、不太了解電腦細節、也不太會去碰電腦設定的用戶，那麼您對於微軟來說就幾乎等於是門戶全開了！

罪狀四：UEFI Secure Boot

最近這幾年的主機板已經捨棄了舊的 BIOS 系統，並且讓 UEFI 流行起來。 UEFI 本身並不是壞事，但其中的 Secure Boot 功能問題卻很大！有些人可能會說這是主機板廠的事情，干微軟、干 Windows 10 什麼事？我的說法是，若不是 Windows 8 / 10 的緣故、若不是微軟從中作梗，又怎麼會讓這些週邊廠商發生這樣的變化？事實上若不是微軟經常從中作梗，電腦產業乃至於整個數位產業應該會發展的更為美好。

從 BIOS 到 UEFI

故事的開始是這樣的，稍微懂電腦 DIY、會自己裝系統的，應該沒人不知道主機板上面的 BIOS 軔體。這個 BIOS 可以看做是主機板自己的啟動系統，在系統上電後、直到把工作權移交給我們安裝的作業系統之前，它掌管電腦的一切行為。 BIOS 的工作至少包含了主機板開機、周圍硬體設備檢查與初始化、搜尋啟動磁碟、搜尋作業系統、然後把作業系統叫起來之後將工作流程移交給作業系統等等的工作。 BIOS 最早是由 IBM 開發在 IBM PC 上使用，賴 IBM 開放 PC 硬體規格之賜，各種 IBM PC 相容的硬體零件廠商如雨後春筍般冒出，其中亦促成了臺灣早期 PC 產業的發展。然而這個 BIOS 的規格和詳細設計並沒有被釋出，可能 IBM 並不覺得它算做硬體吧。那麼缺乏 BIOS 的主機板要怎麼開機啟動呢？於是早期的主機板廠商對 IBM BIOS 進行了逆向工程，仿製出了 BIOS 軔體。

這樣各位有稍稍看懂了嗎？ BIOS 從一開始就沒有明確的規格和規範，實際的規格只有一個：「要擁有和 IBM BIOS 一樣的行為與反應」。因此經過了數十年的 PC 產業發展，各項硬體設備規格都已經更換了數不清的世代，只有 BIOS 一直是那個樣子，幾乎沒有任何變化。幾十年來，當初那個 BIOS 早就已經不符合現代 PC 的需求，但沒有人敢去動它的規格，否則就會面臨不相容的問題。於是一直以來，主機板廠商的軔體工程師都要在極度有限的編碼空間裡面，使用非常老舊的 16 位元指令集編寫 BIOS，並且寫出來的 BIOS 還要能夠與新式的硬體設備溝通協同，這些人實在太令人敬佩！

老舊的 BIOS 不只讓開發工作變得極其困難，也大大限制了硬體設備的發展，於是 Intel 終於看不下去了！他們打算開發一套全新的系統，符合現代需求的、規格明確、完全取代老式 BIOS 的系統架構，並命名為 EFI，就是後來 UEFI 的前身。各位若有過在 BIOS 以及 UEFI 介面上修改主機板設定的經驗，是不是光是在操作介面上就可以感覺到 UEFI 的先進奔放呢？然而實際上 EFI 的發展並不順利，不是指它的技術不成功，而是 EFI 架構一直無法在市場上推動起來。為什麼呢？因為微軟對此興趣缺缺，不願意投注心力做改變。你看如果有一個推銷員要賣你一個新的主機板，說上面採用了什麼最新技術多好多好的，只不過 Windows 不支援這種架構，這主機板需要使用更先進的其他作業系統，請問你會買嗎？請問誰會買單？查了資料我才發現，EFI 其實並不是什麼太先進的技術，早在 199x 年左右就開發出來了， Linux 在 2000 年左右就已經支援 EFI 啟動，然而 UEFI 一直要到 2011 年以後才真正開始流行。難怪不少科技領域大老都說過：微軟是阻礙數位科技發展的兇手！

利用 UEFI Secure Boot 來防堵其他競爭的作業系統

那麼既然微軟對新的 EFI 興趣缺缺，又為什麼在 2011 年突然感興趣了呢？那是因為微軟發現了 EFI 裡面有一個好功能(相對於微軟來說是好功能)：Secure Boot。前面不是說了嗎，BIOS/UEFI 主管了從電源啟動到移交執行權給作業系統中間的工作，而其中的 Secure Boot 功能可以檢查即將啟動的作業系統是否為受信任的系統，若為可信任的作業系統，才將之啟動，反之則拒絕啟動該作業系統。這個設計一開始的目的是為了避免作業系統核心被病毒、木馬等軟體或其他有心人士竄改過，如果各位年紀夠長的話可能就會知道，從前的開機型病毒就屬這類。當然，微軟看上 Secure Boot 功能絕對不是為了用戶的安全 (若微軟真的在乎用戶安全，就不會有那麼多數十年修不好的 Bug 了)，產業人士都知道這是為了防睹用戶安裝其他作業系統！

怎麼說呢？我這樣問你好了，你這十年來有看過或遇過竄改開機啟動區的病毒嗎？所以可以說依據現實層面，沒有多少案例需要用到 Secure Boot 的保護。相對的我再問你，Secure Boot 如何檢核作業系統是否受信任？由誰來決定什麼系統是受信任的而什麼系統不是？這樣你明白了嗎？

詳細的認証方式牽涉到一些密碼學知識，有興趣的人可以另外去研究有關非對稱加密、簽署驗證、以及雜湊值的相關資料閱讀，我這裡就不說明。從 Windows 8 開始終於支援了 UEFI 開機，然後微軟在 Windows 8 認証規格裡面加入了與 Secure Boot 有關的規範 (雖然微軟不是公權力單位，沒認証的硬體也不是不能賣，但認証通過了就可以在產品貼上 design for Windows 8 字樣的貼紙，有廠商敢不認証嗎？) 簡單摘要這規範裡的重要部份為：主機板必須具備 Secure Boot 功能(當然也要預先含入微軟的公鑰資訊)，並且不能讓使用者對其設定進行修改。也就是說，新的 UEFI 主機板只能安裝使用 Windows 8 (以及之後的 8.1 與 10)作業系統，你無法安裝使用其他系統如 Linux、BSD 等。

微軟的防堵策略對使用者造成的影響

大部份的人是不是可能想說反正我這輩子不會去用 Linux 和 BSD 等等其他作業系統，所以與我無干？那就錯了，因為從前還沒支援 UEFI Secure Boot 的 Windows 7、Windows XP 等也無法安裝使用。如果你覺得只有這樣而已那又錯了，因為還有很多第三方的開機光碟、救援工具光碟、自己製做的整合安裝光碟等也都無法使用 (這些光碟能夠不動到電腦上的系統而直接靠自己啟動，其實也是因為光碟內自含了一個小型的開機系統)。總的來說，可以說是微軟將獨家掌握 UEFI 主機板的開機所有權，而你除了微軟所允許的項目外，沒有任何其他選擇！

微軟當時的這個舉動在歐美各地造成產業人士的強烈沸騰與抗爭 (不知為什麼，臺灣好像就都沒有人覺得這樣有什麼不好的感覺)。最終微軟不得不妥協，在 x86 系列上面修改了認証細則；基本與上述一樣，但多加入了：主機板廠商可自行決定要不要加入讓使用者修改 Secure Boot 的設定選項，但預設要為啟動。此後，有些主機板可以開關 Secure Boot、有些甚至可以讓你匯入、修改其他認証公鑰，而也有些主機板完全不提供相關選項(例如曾聽聞 VAIO 部份 laptop 就無法關閉 Secure Boot)。

上面提過 Secure Boot 被微軟的濫用，也導致了以往電腦維修工程師的各種開機工具光碟可能從此失效，然而 Windows 電腦偶而還是會死翹翹需要救援啊，那可怎麼辦？這就是為什麼從 Windows 8 開始，系統內含了一堆有關於還原、完全還原、主機板設定修改工具等神奇工具的原因了。那如果系統完全死掉、或被駭的很徹底，那該怎麼辦呢？那就只能拿一片正版 Windows 8 / 10 光碟重新安裝了！

最終，UEFI Secure Boot 的這些事情對大眾的影響，是剝奪了使用者自主權，從此使用者自己買的機器可能沒有辦法、或難以使用自己所希望使用的作業系統。然而對於微軟來說，這是個太好不過的事情，本來從此可以把所有的使用者鎖在 Windows 上不能亂逃，甚至連自己的舊版 Windows 也一起封殺，還有比這更好的事情嗎？唯一的遺憾就是由於在 Secure Boot 上的一些妥協，成為了使用者不安份使用 Windows 8 / 10 而改用其他作業系統的漏洞，也因此引導出後來微軟協同 CPU 廠商再次封殺 Windows 7 的事情。

接續後篇「Windows 10 十大罪狀(下)」

香港暴動之我思

Tue, 03 Sep 2019 22:47:21 +0800

香港最近並不平靜，我想到今天應該已經沒有人不知曉這件事。這場紛爭從三月開始至今已快半年，不只看似沒有結束的跡象，暴亂程度還在不斷的升級中！做為一個置身事外的旁觀者，除了隔岸觀火外，這整件事情也應當讓我們從中學習並做反省。

回想最初，當時好像是因為什麼「反送中」之類的問題讓港人不開心，所以出來抗議。但事情發展至今，反什麼好像已經沒什麼人知道了，反正就是「反中」；或者說，那些在背後鼓動的勢力已經不再掩飾或掩飾不了港獨的真面目，鼓動無知的港人 – 特別是青年們 – 為其獲取利益的馬前卒。有沒有覺得和數年前的太陽花事件如出一轍？反對的東西變來變去，到後面反什麼也沒人知道，或者說是沒人在乎，反正就是反馬！

我看見的許多臺灣人多嘲笑香港人，覺得他們好像都是白痴一樣，在自己家裡打砸，砸毀香港的基礎建設、還有和平繁榮的城市風氣，破壞商業和生活的經濟環境、和數十年來苦心經營的亞洲金融地位，令周圍虎視眈眈的深圳、上海、臺北有了趁虛而入的機會，最後圖得了什麼？在這當中我們只看見一個小男孩哭鬧著要鄰居買東西給他，不然他就…… 不然他就打爛他自己的腳踏車、撕破自己的衣服裸身在外叫囂，現在還威脅鄰居若不從就要拿著火把作勢要燒毀自己的家。相比之下川普在貿易戰中給出的威脅、或數年前中國大陸抵制日貨的行為還有邏輯有意義的多！

回顧香港，最近的數字顯示的香港經濟衰弱、十五間酒樓倒閉、世界各地對香港的旅遊警示和遊客數的衰減、商店和公司行號的憂心忡忡，香港人最終為自己得到了什麼？當中尤其我個人最匪夷所思想不透的是，這個罷課究竟是怎麼個原理？為什麼學生們會覺得自己不去上課就可以威脅別人怎麼樣？雖然我身為臺灣人私心希望香港的學生繼續不上課、不學習，這樣以後我們就少了一小票競爭對手；罷工繼續、破壞繼續，等香港垮了我們就有機會可以取而代之，若這樣想的話，香港的問題對我們來說好像也不是個壞事！

然而對於臺灣人，若香港的故事只能讓我們幸災樂禍的話，就太沒有價值了！深深覺得我們應該要從這些事當中看看自己、反省自己。我們看人家覺得好笑，那是因為我們置身事外；我們看他們覺得蠢，那是因為不是我們的事。可是可曾想過，人家也是同樣覺得我們又蠢又好笑呢？當我們笑看英國人的脫歐公投、當我們嘲笑希臘的白痴反撙節公投的時候，可曾想想，人家是怎麼看我們在鬧台獨？又怎麼笑倒在每一件鬧出的國際笑話之前？思考到這裡，我就明白為什麼香港人覺得自己是在為自己的未來努力的戰鬥了，因為他們陷入了和我們一樣的意識型態陷阱中！

幾個月前，有香港朋友來臺灣玩，吃喝玩樂之餘我們也進行了不少的談話思想交流，其中令我印象深刻的是，香港朋友對我透露一個他們曾經恐懼的故事：

約莫二三十年前，香港人曾經普遍感受到一股威脅和恐懼。那個時候的臺灣正在努力的建設打造亞太營運中心計劃，而此計劃若成，則香港地位何在？香港將何去何從？香港從前的優勢和繁華是否將一蹶不振？結果日子一天天過去，臺灣的計劃終究沒有了下文，香港人才慢慢的放下心中的恐慌。雖然威脅的消失對香港人來說是件好事，但他們如今依舊不解，也依舊好奇臺灣人的想法，為什麼大好的未來就這麼白白的不要了？

香港人不知道臺灣人在想什麼，但臺灣人，你應該知道當時發生了什麼事情吧？就在在搖旗吶喊中、就在臺灣獨立意識中、就在戒急用忍的呼聲中，我們的未來就這麼被自己玩掉了。與多年後的反服貿運動簡直是如出一轍啊！

當臺灣人熱衷於爭吵什麼中國不中國、臺灣不臺灣的無意義問題時，美國人在笑我們、英國人在笑我們、希臘人也在笑我們，現在連大陸人也在笑我們，當臺灣因為這些亂七八糟又沒有建設性的議題被搶住社會焦點，而忽略了更多更重要也更急切的民生問題、國際局勢、經濟走向時，當臺灣數十年來裹足不前，不斷原地空轉內耗時，全世界仍然不斷前進，不會停下來等我們。當亞洲四小龍之首變成四小蟲之末，當民生凋敝、青年們出走他鄉當臺勞時 (雖然臺灣人愛面子，不承認是臺勞，嘴硬說是打工換宿，但你我都清楚那是什麼！) 這就是我們正在承受的苦果。

香港我看是快完蛋了，不論這次的風波最終是如何收場，香港在經過破壞後、加上中共的忌憚、國際商業間的不信任、還有周圍虎視眈眈隨時想起而代之的城市環繞下，香港此後大概是很難再爬起來了！數十年後的香港人將如何看待今天的事情，我不知道；但如果這次香港的事件可以讓臺灣人以旁觀者的角度，看清事實並重新審視自己，那麼我想香港人壯烈的犧牲將可以為我們留下一點點價值！

半桶高手愛藏私；真正的大師不私藏

Thu, 13 Jun 2019 00:16:19 +0800

我在多年的生活經驗中發現一件有趣的事情，許多各行各業的高手們不喜歡讓你知道行業的秘密，也不喜歡讓你知道他技術的秘密，就是以傳授知識技術做為本業的老師們，不少人也都有藏一手的現象。

「藏一手」這件事似乎是中國人自古即延續下來的傳統。在知識產權不受重視的年代，加上人在社會必須各憑自力拼殺生存的環境，藏手的做法卻實保護了師傅們不被青出於藍的徒弟反過來倒打的悲慘結果，也保障了師傅們的地位和控制利益的權利。當然缺點就是，在學徒沒有自己開創研發新知識門道的情況下，傳承的技術經驗就會愈來愈少直至消逝。

還有另外一種更可悲的人，這種人在各行各業裡都可以看到。在很多不同的地方都可以看到這樣的人，這些人通常是真的在某些地方擁有過人的知識、技術、經驗、或表現，但是他們不願意告訴你 – 事實上他們不願意告訴任何人 – 他們的知識、技巧、或任何與之有關的情資。他們會極其小心的隱瞞自己所知到的事情，不悅於任何的探詢行為，當然他們也不會去參與任何的知識交流分享活動。而追根究底會發現，這是基於不足而產生的恐懼造成。是因為這些人所擁有的知識內涵其實就只有這麼一點點，一旦被人知曉，則他將要喪失其所能與他人競爭的所有優勢，因為人們一旦知曉這些內容，就會發現這些秘密其實多麼的簡單廉價。因此他們必須要努力的保護這些僅有的可憐知識，生怕別人把他偷走了！

好玩的是，我也發現另外有一些人，這些人多半是某些領域中真正的高手、大師等級的人物，他們普遍存在另一種苦惱。他們知道的太多，他們累積的經驗和摸索出的哲理太多，他們往往失落於沒有人能與自己切磋學習，害怕這些畢生的所得有一天會隨他們一同進入墳墓。每當有人表現出探詢其知識的慾望時，他們通常會欣悅的倒出自己的所知，傾囊相授。他們不怕告訴你所有的知識，只害怕沒有人承接這份產業；不怕你探尋所有的秘密，只擔心你消受不了！追到底會發現，原來是他們知道的太多、掌握的太多。知識被人偷去後會影響到自己競爭力的這個威脅是不存在的，其一是因為擁有的太多，其二是真正的高手們早已超越這一切而進入了更高深的層次，使用氣運就可以挪移乾坤。所以這些普通高手們所擔心的事情為大師來說是沒有意義的；反而是高處寒冷又孤單，而這才是那些真正的師傅們所擔心害怕的事情。

雖不知誰是因而誰是果，但看那些擁有的多的人往往不吝於分享，而那些擁有的少的人，往往汲汲營營於保護小利小惠。這讓我想到經書上的一句話：「對那些擁有的，我還要再給；而對那些沒有的，我連他僅剩的，也要從他手中奪去！」

電腦愈用愈慢，該換電腦了，真的嗎？

Sun, 19 May 2019 17:45:56 +0800

有時候我很容易聽到這樣的一句話：「我的電腦太舊了，跑的很慢，改天應該要買個新的！」似乎很多人都覺得，電腦隨著使用的時間增加而愈來愈緩慢遲滯，這是一件非常正常也非常合理的事情，畢竟在我們的生活經驗裡，所有的機器、甚至是人，大都遵循著愈老愈無力的規則是吧？

說實在的，我平常有在蒐集親朋好友的淘汰電腦的習慣，而我就特愛這種別人因為年歲而淘汰掉的機器。因為這種機器通常整臺都是好的，沒有任何硬體故障，只要稍加整理，又是一尾活龍。那麼這種好好的機器為什麼會被別人丟出來呢？問到底差不多就會得到「老舊了、太慢、不堪使用」這樣的答案。

看到這裡應該就可以了解，我認為電腦因為老舊而變慢這事是個假的問題，至少不是硬體本身的問題。這時可能有些人要反駁了，說我之前的什麼什麼電腦真的是愈用愈慢啊，後來慢到實在受不了之類的。難道說這些人的感受是假的嗎？不，通常這些人的親身體驗都是事實。

我的重點在於，絕大部份的電腦愈用愈慢的原因與老舊無關、與硬體設備無關，並且通常在經過一些整理處理後就可以回復正常。為了減少電腦設備無端被丟棄，也為了拯救地球環境，這裡我就要來分析電腦為什麼會變慢的各種原因，並提出對應的解決方法。

原因：硬體老化、髒汙

首先，數位裝置與類比式裝置不同，絕大多數的情況下並不會因為設備老化而變慢。例如，處理器的時脈不會因為用久了而從 1 GHz 掉到 0.8 GHz，記憶體也不會因為用久了而容量從 1 GB 變成 0.8 GB， 7200 rpm 的硬碟只要沒壞，用多久都仍然是 7200 rpm。這並不是說電腦零件不會老化，而是數位電子零件的老化所造成的影響是使得裝置運作不穩定，用白話文來說就是會導致電腦常死當機、自動重啟、黑畫面藍畫面或花畫面之類的現象，而不是使零件效能降低；所以我們平常所感覺到的電腦變慢的問題，十之八九與設備老舊無關。另一種說法就是只要設備沒壞，它就可以達到規格上的性能。

大概只有一種非常特別的情況會導致舊的電腦硬體變慢：散熱裝置的老化或疏於維護清潔，因散熱不良使得處理器溫度異常升高，此時有些處理器會啟動保護機制而停止工作，這會導致電腦當機無反應；而有些具有自動調節時脈功能的處理器可能會自動降頻降載，這時硬體的辦事速度就是真的變慢了！

在我小的時候曾經有親友送給我們一臺舊電腦，就是舊到他們用不下去而不想再用的電腦；而我們家則是有得用就不錯了，就開心收了下來。這臺電腦有點怪，用著用著就會當機，重開都沒有用，我們發現要強制關機後休息一會再開才會正常。但隨者日子過去，這臺電腦當機的時間愈來愈短，從一天當機一次變成兩三個鐘頭當機一次，再變成不到半小時當機一次；每次需要的休息時間也愈來愈長，從一兩分鐘的休息時間慢慢變成要休息三十分鐘以上才能再次正常開機。有一天再也受不了，我把機箱拆開一看就傻眼了，CPU 散熱片已經被灰塵塞滿，滿到了最上面的風扇底部！經過清理散熱片和風扇以後，這臺電腦從此就正常了。

處理對策

如果你也遇到硬體老化的問題，而且它竟然沒有導致你的裝置故障，而是讓設備變慢的話：請拆開機殼、清潔內部所有灰塵、替換失效的風扇、並重塗散熱膏，然後你的電腦很有機會能就此重新活過來。

原因：新軟體、新系統，導致更大的硬體需求

如果你是一個喜歡追求新鮮事務的人，喜歡安裝新軟體、喜歡升級新程式、喜歡更新新系統的話，那麼你一定很快就會覺得電腦不敷使用了！

軟體程式的開發基本都是以當時市面上裝置的普遍分佈情況做為參考標準，就算考慮低配置的裝置也通常指的是同一個時代下的低配置。所以今年發佈的軟體在今年的主流配置下通常不會有什麼計算資源不足的問題，但對於數年前的裝置而言可能就會應付的有點吃力。例如今年(2019)市面上大部份的桌電膝電都有 8 GB 到 16 GB 左右的記憶體容量，因此各種中型應用程式大概都會消耗數個 GB 的記憶體資源，甚至作業系統一啟動可能就先瓜分個 4 GB 來用；然而十年前的電腦(2009)可能記憶體普遍數字為 2 GB 到 4 GB，所以那個年代的作業系統一啟動大概就只瓜分不到 1 GB 的記憶體，然後各應用程式的記憶體需求大約也在數百 MB 之譜。那麼若拿 2009 年的電腦來安裝執行 2019 年的程式、系統，那自然就會感到吃力。

說到底，在這種情況下其實你的電腦並沒有變慢。你的電腦還是那臺電腦，它的運算速度仍舊是那樣，沒變慢也沒變快；變的是環境，是你的需求變大了，使它不能再負荷你的要求。

處理對策

舊的電腦請安裝執行符合它時代的各式軟體，不要在沒有必要之下老想升級新系統、安裝新版軟體。例如當時跑 Windows XP 非常順暢的電腦，為什麼一定要升級到 Windows 7 呢？跑 Windows 7 的電腦又為什麼非要升級成 Windows 10 呢？如果 Office 2000 可以滿足你的需求，為什麼一定要安裝 Office 2019 呢？想想你升級新軟體是因為新軟體有什麼你需要的功能？還是只是想要新的而已？把握這點原則，不進行不必要的升級，就可以讓你的電腦繼續保持順暢的處理效率。

如果因為舊時代的軟體缺少某些所需要的當代軟體功能的話，在有選擇的情況下，也可以選擇安裝在當代軟體中特別考量低資源配置裝置的產品，例如使用新的 AbiWord 替代舊的 LibreOffice Writer、使用新的 LXDE 替代舊的 KDE、使用新的 FireFox 替代舊的 Google Chrome 等等。

原因：電腦病毒、木馬程式

電腦中毒、被入侵等情況也有可能讓電腦變慢。雖然大部份現代的病毒與木馬通常都傾向安安靜靜的做他們的事情好不被你察覺，但部份的惡意程式意在偷用你的電腦資源，比如說利用你的設備幫他挖礦的惡意網頁廣告、利用你的網路做為跳板幫他駭進別人電腦或發起 DDOS 攻擊的木馬程式、或者使用你的處理器幫你加密電腦檔案的綁架病毒等等。在這些情況下，因為您寶貴的硬體計算資源都被別人分去使用了，只剩一部份來處理您真正授予執行的工作，那當然就變慢了。

處理對策

請事先做好各種資安防護工作，電腦不中毒、不被入侵，自然就沒有這些問題；若不小心中獎了，請直接格式化硬碟並重新安裝作業系統即可解決！

原因：系統檔案與資料系統紊亂

即使電腦沒有中毒、都使用符合它時代規格的軟體、硬體也都排熱順暢，電腦仍有可能隨著使用而愈來愈慢，這主要是因為有些作業系統的設計不良導致。例如赫赫有名的 Windows 系統在經過反覆的安裝與解除各種軟體後，會在系統組態資料庫遺留累積的垃圾資料，或是錯寫某些關鍵資料而沒有還原；或是經過多次的系統、驅動程式、與應用軟體更新操作後，可能會導致系統關鍵檔案出現缺失、衝突、或版本混亂等問題；或者只是持續開機時間久了以後就會讓系統效率莫名的低下。這些現象在 Windows 9X 和 XP 時代可是家喻戶曉的產品特色，新版本的 Windows 雖對此有些改善而較不明顯，但問題仍然存在。

處理對策

如果您使用的作業系統具有會愈用愈慢的特色，請在不用的時候把它關機而不要經常開著不關，建議至少每天關機一次；若系統的檔案與資料庫出現永久性問題而無法用重新開機來解決的話，簡單的格式化硬碟並重新安裝作業系統就可以解決這個問題！

原因：檔案系統碎片化

磁碟檔案系統在經過一段時間的資料讀寫操作後會產生檔案資料碎片化的問題，而有些檔案系統對於資料的碎片化較為敏感，會使讀寫響應速度降低，使得系統反應緩慢，例如著名的 FAT 檔案系統家族在這個問題上就很明顯， NTFS 檔案系統對於碎片化資料的讀寫有所加強但仍舊受到影響。

十多年前我曾經幫鄰居處理過一臺電腦，這臺電腦的帳面規格和我家當時的電腦不相上下，但是用起來就是很卡很慢，任何一個操作都要等上好一陣子。後來我花了將近一小時，把磁碟進行重組後，它在日常操作的速度立刻就順暢了！

簡單來說，就是某些作業系統只能使用某些檔案系統，而某些檔案系統用久了就會變慢，而檔案系統反應慢了就會回來導致作業系統在檔案相關操作時變得遲鈍。

處理對策

如果您使用的檔案系統具有愈用愈慢的問題，請記得偶爾執行一下磁碟重組程式即可。若不知道該多久重組一次磁碟的話，建議每半年執行一次。

另外請注意，不要對固態硬碟(SSD)執行磁碟重組工作！固態硬碟的原理和傳統磁盤硬碟完全不同，固態硬碟不會有碎片化導致讀寫變慢的問題，反而磁碟重組行為會無端消耗它的使用壽命。

原因：垃圾桶內檔案太多

在一般的桌面環境下刪除檔案一般都會進到一個叫「垃圾桶」的地方，而不是直接刪除。我平常刪東西都喜歡讓檔案就留在垃圾桶裡面而不去清它，除了還有機會把檔案撿回來這個原因外，一次清除這些檔案時會看到資源管理器顯示的磁碟使用量從極高一下子變低，算是個人無聊的樂趣之一。結果我發現當垃圾桶的東西太多時，會讓開機後進到桌面環境的時間變很久，我的桌面系統好像會在啟動時去掃描分析垃圾桶的狀態，讓我從登入到桌面環境備便的時間可以拖長到幾十秒。最後就是把垃圾桶的東西清掉，就回復正常了。

處理對策

如果你的桌面環境會因為垃圾桶內東西太多而變慢的話，請記得常常清理你的垃圾桶。

原因：檔案、資料太多，把固態硬碟(SSD)塞太滿

這幾年固態硬碟(SSD)似乎蠻流行的，新機不管三七二十一幾乎都要安上固態硬碟才算是趕得上時代。大家一窩蜂的裝上 SSD 不外乎就是聽說它的速度超快，然而 SSD 的速度其實是有條件的，在某些不利的情況下 SSD 甚至能夠比傳統磁盤硬碟(HDD)慢好多！ SSD 與 HDD 從基本原理上就完全不同，所以很多特性和禁忌等也是差異極大。然而這裡我不想展開太多有關它們的差異細節與調校方式等，因為光這就可以自成一個主題；這裡只抓一個一般人最容易誤犯且不容易被其他技術手段所改善的問題，即儲存空閒比。

SSD 內的檔案資料塞的愈滿，會導致裝置之寫入速度愈慢，除此之外還會加速裝置壽命的消耗。當前的各種固態硬碟和記憶卡等由快閃記憶體做為核心的設備，其控制器通常都設有程度不等的最佳化手段，以加速操作響應速度並延長裝置壽命，然而究其原理不外乎就是最大程度的利用閒置空間進行任務分擔的各種不同方法。所以就算某些 SSD 再怎麼標榜它的控制器有多優秀，當你的空閒空間給的不夠時，巧婦也難為無米之炊啊。所以你也許會發現，容量接近滿載的 SSD 其資料寫入速度其實可能比 HDD 還慢；若經常性的讓 SSD 維持滿載狀態，則手上的 SSD 可能很快就會故障了！

處理對策

若你的電腦裝備了固態硬碟(SSD)，請不要死命的往裡面塞檔案，請多留些閒置空間給你的硬碟控制器去做利用。若你沒有概念閒置空間到底要留多少比較理想的話，建議平常大約保持可用空間佔整個硬碟空間的四分之一到一半左右即可！

原因：心理因素

有的時候電腦本身可能並沒有什麼狀況，但我們感覺它好像不夠快了，這可能就是心理因素所造成。更詳細的說，因為市場日新月異，周圍的朋友、辦公室、咖啡廳等環境見到的電腦愈來愈高檔，回頭使用自己的電腦，在對比之下好像就變慢了。

舉個例子好了，一兩年前的電腦開始主打兩秒鐘開機之類的特色，這時大家的電腦好像突然就變慢了，開始無法忍受超過三十秒的開機時間。但是你的舊電腦剛買來的時候就需要三十秒開機，現在依然是三十秒開機，為什麼那個時候你不覺得慢？而現在就慢了？

另一個例子，當大家爭先恐後的換裝 SSD 的時候，還在用 HDD 的電腦好像又老又慢一樣，但是以前沒裝 SSD 的時候它也很快啊。

電腦還是那臺電腦，它可能並沒有變慢，而是環境裡的其他電腦都變快了，是你的胃口變大了！

處理對策

既然是心理問題，那除了調適自己的心態外，就沒有什麼有效的對策了！當然你可以不滿足於現狀，也可以汰舊換新，做這些事情本就沒有錯，只是要記得是你自己的要求變高了，而不是電腦變弱了。

原因：Windows 10 作怪

很多時候，電腦慢其實不是中毒、檔案太多、或是灰塵的問題，而是在你電腦上運作的 Windows 10 在搞怪！這不是我在說而已，Windows 10 的各種惡形惡狀早就被眾多的使用者們罵到臭頭了，網路隨便搜尋就可以看到一大堆抱怨的、中鏢的、死掉的各種讓人不知該哭還是該笑的案例。不過為了避免變成純粹的情緒話語，我還是稍微分析一點點為什麼 Windows 10 會導致你電腦變慢的原因。

首先是大家合理懷疑微軟從 Windows 10 開始(或是從 Windows 8 就已經開始？) 移除了作業系統對傳統硬碟(HDD)的最佳化演算工作，就算沒有主動移除它們，也是刻意放爛它不管。因為我們都看不到 Windows 內部的實做，所以可能沒有辦法確認這件事，但是從大眾實際上的使用經驗可以支持這種懷疑 (https://www.google.com/search?&q=windows+10+hdd+100%25)。比如說以往運作 Windows 7 的電腦都很正常順暢，而在升級為 Windows 10 後就發生各種緩慢、卡頓，非要把硬碟換成 SSD 才會順，我想這就是為什麼這幾年大家一窩蜂的去裝 SSD 的原因之一吧！

Windows 10 還會在背景執行許多大量的運算，有時候會佔用過多的運算資源，導致使用者的操作變得緩慢卡頓。沒有人搞得清楚系統在背景到底實際在算什麼東西？目前的推測是這些運算可能包含：信任運算、使用者行為記錄分析與回傳、更新升級相關運算與下載、廣告投送…… 等。導致時常讓電腦的處理器、記憶體、與網路等資源維持在高負載狀態，有些功能(主要應該是更新升級相關)還會大量佔用電腦的儲存空間，導致網路上常怨聲載道。

另一個大問題是 Windows 10 的更新機制。由於微軟的商業策略，Windows 10 設計上採用了無法關閉的強制更新機制，時常自動在背景執行的更新工作是導致系統變慢、變得不穩定的最大因素，也是網路上大家抱怨最嚴重的一塊。此外，Windows 10 的自動更新也會導致我們在前面提到的應對對策無效。比如說你想要繼續使用你五前年的電腦，依照我們的要點，你的電腦最好安裝運作五年前等級的軟體配置，然而 Windows 的自動更新強迫你必須要隨時更新微軟的最新產品！也就是說你的電腦會自動變慢(因為軟體負載愈來愈大)，使得一段時日後你必須要對硬體裝置汰舊換新才能繼續負擔當時的軟體應用環境；最終，人們被迫拋棄舊的電子設備，即便這些硬體裝置本身狀態良好！

處理對策

既然是萬惡的 Windows 10 造成的問題，只要不要使用它就好了，當然前題是在你擁有其他選擇方案的情況下。

如果老電腦以前是運作 Windows 7、XP 的，何必改裝成 Windows 10 呢？而對於新的電腦設備，若您的技術能力允許，也許也可以考慮安裝 Windows 7 而非 Windows 10；雖然這個方案可能沒辦法長長久久，但至少在直到 2020 年微軟正式停止對 Windows 7 的維護之前，這都是一個確實可行且保險的方案是吧？

當然，若您能夠直接捨棄整個 Windows 產品，改用其他作業系統方案的話，也不失為一個更好的選擇！

總結

一般使用者雖然沒有太多電腦相關知識，當電腦變慢時往往也不知道到底是什麼原因造成；但綜和上面各點說明，我們其實可以得到一些簡短的準則。只要依照這些建議的做法，老電腦應可以再用好久：

電腦不要一直放著不關機，最好每日、或每週關機一次，除非您使用的作業系統沒有開機愈久愈慢的問題。
垃圾桶不要塞太多東西不刪。
固態硬碟不要裝的太滿，建議保留四分之一左右的空間為空。
不要在沒有必要下無意義的升級新的軟體、系統。
定期將電腦軟體系統移除乾淨後重新安裝，大約一年一次即可。
定期清理灰塵髒汙、改善散熱條件，大約一年一次即可，除非您的工作環境落塵量大。
能的話，不要安裝 Windows 10；可能的話，最好連 Windows 都不要用。

我的電腦終於壽終正寢了

Thu, 09 May 2019 22:00:48 +0800

前幾天電腦突然就開不了機了，反正我還有其他膝上電腦可用，就沒有急著處理它。昨天拿去送修，結果好悽慘，記憶體、顯示卡都有故障，然後主機板也被測出不穩定，時好時壞。

這整個看起來就像是多重器官衰竭的病人一樣，已經不是換什麼零件可以再撐多久的事情了(或者說不值得)，看起來就是真的走到生命盡頭的樣子。其實我對這樣的結果並不感到意外，因為這臺電腦真的已經很老了。

我記得大概是 2009 年，那年我還在念碩士，前一臺電腦壞掉後購買了這臺電腦，算一算只要再過幾個月就滿十年了。這是我第一臺花自己的錢買的電腦，因為我當時的論文要計算 3D 流場，只靠實驗室發的電腦怕是來不及畢業，所以這臺電腦砸了我大概 3、4 萬，配到以當時標準來看算蠻高檔的配置。記得當時我堅持記憶體一定要插滿 4 GB (32 bits 的 Windows XP 最多只支援 3.5 GB 的記憶體，所以 4 GB 就是頂了) 才勉強足以計算數量以百萬計的計算網格。最終因為這臺電腦到底加速了多少論文時間可能已經難以計算，不過它倒是出乎意料的變成陪伴我最久的單一電腦，久到所有聽聞的人都覺得不可思議！

那個時候的我除了熱衷於寫程式寫遊戲以外，其實電腦相關基礎並不強，也不知道什麼遠端控制的東西，所以常常是騎著摩托車在淡水後山的宿舍和學校的實驗室之間往返，現在回想起來也是很好笑。多虧當時同宿舍的學長熱心幫我選單、組裝，還包辦了後面好幾次的維修，讓我免去面對一堆看不懂的規格等各種問題，最終才能順利的組出這臺超強電腦。之後的十年間，雖然換過幾次顯示卡、電源供應器，以及換過無數次的硬碟和光碟機等等，但整臺主體和主要機件一直都是 2009 年的那些零件，完成了跨越十年的使用歷程。

時至今日，面對這臺電腦走到生命的盡頭，我已不再如同從前那樣的徬徨焦慮，反而覺得坦然釋懷。我想可能是因為我還有其他膝上電腦可以暫時頂替，加上我自己平常檔案備份都有做足，所以才能這麼的保持平常心吧！為此我要感謝我的老師，因為長久以來所累積的知識學問和技術，才讓我今日能夠倚仗著充足完善的準備而能有恃無恐。接下來又要開始尋覓新的電腦了，而這我想又會是一段挑戰的旅程……

C 呼叫 C++ 函式的方法

Mon, 08 Apr 2019 23:25:00 +0800

由於 C 與 C++ 基於歷史因素、互相相容、以及地位相近的關係，他們的程式碼很有機會會在一個專案中並存。但畢竟兩者的差異還是有點大，於是在互相使用對方的東西的時候，有時候會遇到一些技術上的小麻煩，這裡我就來解釋有關 C 語言程式碼要如何呼叫 C++ 函式的相關技巧。

首先，為什麼我不關心 C++ 要如何呼叫 C 函式？這是因為這種案例幾乎不存在問題。 C++ 號稱是 C 的超集，C 有的東西絕大部分都被 C++ 支援，不用特別改變什麼，最多就是把 name mangling 的部份小小宣告修飾一下就完事了，實在沒什麼好說的。相反的，C++ 多出很多 C 所沒有的語法等特性，所以在 C 一般來說是沒辦法去呼叫沒有經過一些特別處理的 C++ 函式的。

概念原則

C 與 C++ 基本上很多機制都還是完全相容的，而 C 呼叫 C++ 函式所遭遇的困難追根究底其實就是以下兩點：

Name mangling 規則不同，所以無法找到 C++ 函式的符號。
函式介面出現一些 C 所沒有支援的語法，使得 C 編譯器無法辨認函式簽名、C 程式碼也無法提供所需的函式參數或呼叫方式。

那麼解決的方法就是讓 C++ 模組提供一些符合純 C 要求的函式介面給 C 程式碼呼叫即可。這裡注意我們不是要把 C++ 程式碼整個以純 C 語法改寫，如果這樣做的話，又和苦用 C++ 來寫模組呢？而且這樣的話，也無需使用 C++ 編譯器，那麼本文所探討的問題也就不存在了。我們只需要在「C 編譯器看得到的地方」使用完全符合 C 語法的內容，也就是只需提供符合 C 語法的函式介面，必要的時候增加一些包裝函式來轉換某些內容即可！

呼叫單純普通的 C++ 函式

假設我有一個 C++ 模組，裡面有一個函式：

int AddValues(int a, int b)
{
    return a + b;
}

若在 C 程式裡呼叫它的話，可能會發生「undefined reference」連結錯誤，這是因為 C 和 C++ name mangling 不同的緣故，所以找不到函式符號。解決的方法就是加上 extern "C" 來告訴 C++ 編譯器說這是一個 C 規格的函式，讓 C++ 編譯器使用 C 的規則來看待它。最後這個函式應該會變成下面這樣：

標頭檔裡：

// 因為 C 並沒有 extern "C" 這個關鍵字，在 C 編譯時反而會發生問題，
// 所以放了 __cplusplus 保護，好讓 C 編譯器看不到 extern "C" 的存在。
#ifdef __cplusplus
extern "C" {
#endif

// 這裡可能還有很多別的函式宣告、型態宣告等等等等……

int AddValues(int a, int b);

// 這裡可能還有很多別的函式宣告、型態宣告等等等等……

#ifdef __cplusplus
}   // extern "C"
#endif

程式碼檔裡：

// 這裡一般就不用再寫上 extern "C"，因為編譯器已經從函式宣告那裡知道了這件事。
int AddValues(int a, int b)
{
    return a + b;
}

這樣，C 程式就可以順利的呼叫這個函式了。

此外，使用 C 規則來處理函式就意味著一些 C++ 所支持的特性是無法被使用在這些 C 介面函式的，若一不小心使用到這些語法特性，則可能會發生編譯錯誤。這些無法被使用的特性有：

同名函式重載(function overload)
模版(template)
名稱空間(namespace)

呼叫包含常見 C++ 擴展型態參數的 C++ 函式

在解決函式符號問題後，接下來會遇到的困難大概就是那些在 C++ 程式裡經常出現的語法或經常傳遞的 C++ 物件了，比如說字串等。這些東西都需要改寫為 C 所支援的寫法：

預設參數：

C 不支援預設參數，請把它拿掉，然後每次呼叫的時候都老老實實的寫上全部的參數吧！
參考傳遞：

C++ 的參考型態函式參數可以節省許多賦值傳遞的開銷， C 雖沒有參考型態，但有作用非常類似的指標，因此請把傳遞參考改成傳遞指標吧。
字串與陣列：

嚴格來說，C++ 也沒有語法上的字串或陣列，只有標準程式庫提供的字串類別，但是因為有些陣列、特別是字串實在是太常以類別物件的型態出現在函式參數裡了，所以還是值得說明。 C 函式只能傳入指標型態的陣列，所以請將參數裡的 std::string& 或 const std::string& 通通改成 char* 或 const char* 吧，其他型態的陣列也請比照進行類似的變換。如果需要傳出字串或陣列資料，則請比照 C 語言裡的常用通用方法！

如果你能夠改寫 C++ 函式的介面規格的話就直接改寫吧，這樣可以省去一個轉呼函式的開銷，除了當別的 C++ 程式呼叫這個 C++ 函式時可能會稍微煩瑣一點以外。而如果因為任何緣故不能夠直接改寫這個函式介面，那就需要再寫個包裝轉呼函式了，下面以一個範例來說明使用轉呼函式包裝一個 C++ 函式的方法：

標頭檔裡：

#ifdef __cplusplus

// 這是我們想要給 C 程式呼叫的 C++ 函式，
// 因為用了 __cplusplus 包裹起來，所以 C 編譯器是看不到它的。
int ShowName(const std::string &name, const std::string &family = "");

#endif  // __cplusplus

#ifdef __cplusplus
extern "C" {
#endif

// 這是實際提供給 C 程式的函式，用來包裝我們的 ShowName 函式。
// 注意我變換了名稱，以規避同名函式重載的問題。
int show_name(const char *name, const char *family);

#ifdef __cplusplus
}   // extern "C"
#endif

程式碼檔裡：

int ShowName(const std::string &name, const std::string &family = "")
{
    std::string totalname = name + ( family.empty() ? "" : " " ) + family;
    std::cout << "You are: " << totalname << std::endl;
    return totalname.length();
}

int show_name(const char *name, const char *family)
{
    return ShowName(name, family);
}

呼叫包含類別型態參數的 C++ 函式

有的時候我們的函式就是需要傳遞一些類別物件，這些物件可能是自訂的也可能是標準程式庫裡的，而且這些物件可能不像字串那樣有標準通用的簡單等效形式，那要怎麼辦呢？簡單的答覆就是，傳遞物件的指標就好了！ C 語言支援指標，而指標的另一端可以是任何型態，就算是未知的型態也無妨。

我們可以用指標型態簡單的解決參數傳遞問題，所以真正的問題不在物件的傳遞上，而是在類別物件的擁有與管理上。既然 C 不支援 C++ 的類別，又如何能夠知道類別的尺寸大小、該如何初始化、以及該如何銷毀等細節呢？所以我們會需要同步包裝一些類別物件的建立與銷毀相關函式給 C 使用，總之重點原則就是： C 只能透過指標經手並傳遞類別物件。下面以包裝一個需要接收 std::map 型態菜單的餐點點單函式做為例子：

標頭檔裡：

#ifdef __cplusplus

// 這是我們主要要包裝的函式。
void OrderDinner(const std::map<std::string,unsigned> &menu);

#endif  // __cplusplus

#ifdef __cplusplus
extern "C" {
#endif

// 這裡為了節省一些其他的型態相關處理敘述，直接使用 void* 做為菜單物件的型態，
// 但在實際用途上我們應該為它定義一個合適的型態，
// 除了增加閱讀性以外，也讓編譯器能為我們進行型態檢查。
void order_dinner(const void *menu);

// 因為 C 程式無法直接創建與使用類別物件，
// 所以要同時提供讓 C++ 程式代為執行這些工作的包裝函式。
void* create_my_menu(unsigned appetizer, unsigned main, unsigned dessert);
void release_my_menu(void *menu);

#ifdef __cplusplus
}   // extern "C"
#endif

程式碼檔裡：

void OrderDinner(const std::map<std::string,unsigned> &menu)
{
    std::cout << "Your order list:" << std::endl;
    for(auto iter = menu.cbegin(); iter != menu.cend(); ++iter)
        std::cout
            << "* "
            << iter->first
            << ": "
            << iter->second
            << std::endl;
}

void order_dinner(const void *menu)
{
    // 因為我們沒有額外處理型態，只簡單的用 void* 代表一切，
    // 所以這裡免不了需要一些比較難看的轉型工作，下面亦同。
    auto *instance =
        static_cast<const std::map<std::string,unsigned>*>(menu);

    OrderDinner(*instance);
}

void* create_my_menu(unsigned appetizer, unsigned main, unsigned dessert)
{
    auto menu = new std::map<std::string,unsigned>;

    (*menu)["appetizer"] = appetizer;
    (*menu)["main"] = main;
    (*menu)["dessert"] = dessert;

    return menu;
}

void release_my_menu(void *menu)
{
    auto *instance =
        static_cast<std::map<std::string,unsigned>*>(menu);

    delete instance;
}

而在 C 程式裡，它可能會被這樣使用：

void *menu = create_my_menu(3, 5, 7);

order_dinner(menu);

release_my_menu(menu);

呼叫 C++ 類別成員函式

由於 C 沒有類別，自然的也不知如何呼叫類別成員函式。而解決方法也很簡單，按照前面的思路為所有需要的成員函式提供轉呼函式包裝即可，這裡直接看範例。

標頭檔裡：

#ifdef __cplusplus

// (提醒您，這個地方只有 C++ 看得到)
// 這是我們要提供給 C 程式使用的類別，包含幾個簡單的成員函式。
class Point
{
private:
    float x, y;

public:
    Point(float x, float y) : x(x), y(y) {}

public:
    void Set(float x, float y) { this->x = x; this->y = y; }
    float Abs() const { return sqrt(x*x + y*y); }
};

#else   // __cplusplus

// (提醒您，這個地方只有 C 看得到)
// 這裡是一個小技巧，在 C 程式下定義一個與我們的類別同名的結構別名。
// 至於結構的具體內容不重要，因為我們在 C 程式下只需要使用它的指標型態而已，
// 而與類別同名，可以讓我們的 C++ 程式不需要一堆醜陋的轉型。
typedef struct Point Point;

#endif  // __cplusplus

#ifdef __cplusplus
extern "C" {
#endif

// 與前面的例子相同，我們亦需同步提供取得、和歸還類別物件的方法。
Point* point_create(float x, float y);
void point_release(Point *self);

// 注意這裡又是一個小技巧，既然這些函式是成員函式的包裝，
// 我把類別物件的指標命名為 self 來類比 C++ 的 this 指標
// (因為 this 是 C++ 關鍵字而不能使用)，
// 並且我還把類別物件的指標都設為函式的第一個參數，以相似 C++ 成員函式的慣例。
// 雖然這些小地方的設定並不是必要的，但這麼做確實有助於閱讀理解，
// 特別是對於那些本來就熟悉 C++ 的人。
void point_set(Point *self, float x, float y);
float point_abs(const Point *self);

#ifdef __cplusplus
}   // extern "C"
#endif

程式碼檔裡：

Point* point_create(float x, float y)
{
    return new Point(x, y);
}

void point_release(Point *self)
{
    delete self;
}

void point_set(Point *self, float x, float y)
{
    self->Set(x, y);
}

float point_abs(const Point *self)
{
    return self->Abs();
}

而在 C 程式裡，它可能會被這樣使用：

Point *point = point_create(3, 7);

point_set(point, 2, 6);
printf("Point abstract value: %f\n", point_abs(point));

point_release(point);

在嵌入式裝置上使用 C++ 進行開發：G++ 實做篇

Fri, 05 Apr 2019 09:00:00 +0800

這篇是承接我之前的文章「在嵌入式裝置上使用 C++ 進行開發：概念篇」，以實做的角度出發，提供使用 GNU G++ 為嵌入式裝置編寫 C++ 程式的方法。

把 C++ 編譯器般上嵌入式的建置環境中大約需要以下步驟：

關閉 C++ 編譯器的部份功能支援。
避免使用某些成本較大的 C++ 特性。
移除編譯器提供的 C++ 執行時期程式庫。
解決因移除基礎程式庫後所缺失的某些必須之元件。

關閉編譯器部份功能

加入下列編譯選項以關閉 G++ 部份功能支援：

-fno-exceptions: 停用例外處理機制。
-fno-rtti: 停用 RTTI 機制。
-nostdinc++: 不搜尋 C++ 標準標頭檔，等同禁用 C++ 標準程式庫。

避免使用部份功能

除了那些由編譯器支援的執行時期機制必須要關閉，否則就算你不去使用它也不能避免它們對程式的影響之外，有一些其他高成本的功能是編譯時期完成的，只要不去使用它們就沒事了，如模版與多重繼承等等。

除了自己小心不要寫上包含這些功能的程式碼之外，如果您使用的 G++ 在版本 6 以上的話，G++ 還提供一些編譯警告的選項，讓它在發現你一不小心使用這些功能的時候給你一些警告。請加入下列編譯選項以開啟這些警告訊息：

-Wtemplates: 對模版的使用發出警告。
-Wnamespaces: 對名稱空間的使用發出警告。
-Wmultiple-inheritance: 對多重繼承的使用發出警告。
-Wvirtual-inheritance: 對虛擬繼承的使用發出警告。

移除 C++ 程式庫

想要程式不連結 C++ 相關程式庫有一個很簡單的做法：把所使用的連結器從 G++ 改成 GCC 即可！

G++ 和 GCC 是一樣的，你甚至可以拿 GCC 來編譯 C++ 程式碼， G++ 比起 GCC 的不同就是會主動多連結一些 C++ 基礎程式庫，所以你其實也可以顯式的加上 C++ 基礎程式庫的連結選項來使用 GCC 編譯與連結 C++ 程式，例如：

gcc main.cpp -lstdc++

這個例子只是在說明，GCC 和 G++ 在經過一些選項配置之後完全可以互換使用。因此最終，使用 GCC 來連結程式就可以剔除與 C++ 程式庫的連結。

解決缺失元件問題

當移除了 C++ 程式庫後，可能會讓我們遭遇不少「undefined reference」的問題，這些問題大約可區別為兩種類型：第一種狀況是可能你的程式碼、或你所使用的第三方程式庫呼叫了一些需要 C++ 程式庫支援的功能，比方說 cout。對於這種錯誤的處理方式就是拿掉或改寫這些程式碼，畢竟我們的本意就是要剪裁一些 C++ 的功能是吧？如果是第三方程式庫的話，那可能就表示這個程式庫不適合嵌入式執行環境，請換掉它吧。

至於第二種狀況則是 C++ 程式庫內真的包含一些需要且必須的、非常基本的功能，如果我們真的要去避免使用這些功能的話，可能會失去我們當初想要用上 C++ 的初衷。這種情況下就需由我們自行實做相關的功能來補上，也許我們把它包裝成一個靜態程式庫，然後給它命名為 libMyTinyStdCpp.a？

以下列舉這些可能會遇到的錯誤，並說明需要由我們自行實現的功能：

undefined reference to “operator new(size_t)” or
undefined reference to “operator delete(void*)”

這個錯誤表示你的程式碼裡使用了 new 和 delete 來建立物件，而連結器找不到對應的函式 (C++ 程式庫被我們取消了，還記得嗎？)。捨棄 new/delete 不用而改用 malloc/free 不能解決我們的問題，因為它們不會去執行物件的建構子與解構子；然而類別自動建構解構也是我們之所以想要用上 C++ 的一大原因，若捨棄 new/delete 不用則我們勢必還要為物件的建構解構花費更大的力氣，因此迴避這兩個運算子的做法並不實際。

為此，我們必須要自己提供 new 和 delete 運算子的函式實做，最簡單的方法就是製做一個轉呼叫 malloc/free 的函式：
```
  void* operator new(size_t n)
  {
      void *p = malloc(n);

      /*
       * 這裡記得檢查 p 為 NULL 的情況並做出處理，
       * 由於通常例外處理機制也被我們停用了，因此不適合拋出例外，
       * 建議可直接回報錯誤並終止程式。
       */
      if( !p ) ABORT_AND_REPORT_ERROR();

      return p;
  }

  void operator delete(void *p)
  {
      free(p);
  }
```
上面這個範例直接簡單的為所有記憶體的分配釋放需求轉呼叫 C 的對應函式，而若你基於任何目的需要自行管理記憶體，比方說想要控制記憶體碎片的發展，則可以把這兩個函式替代為你自己的實做版本。
undefined reference to “__cxa_pure_virtual”

這個錯誤表示你的程式裡面有使用到純虛函式。在執行時期，當遇到呼叫一個未存在實做的虛擬函式時， __cxa_pure_virtual 便會被呼叫。由於我們想要導入 C++ 應該也是看上了他的多型特色，因此迴避純虛函式的做法顯然也不實際。

由於編譯器在編譯時期就會阻擋想要建構未實做完成的類別實體的程式碼通過編譯，因此 __cxa_pure_virtual 這個檢查函式其實只有在非常不尋常的時候才會被執行，那麼我們就可以很簡單的提供一個實做版本，直接列印錯誤訊息並終止程式，好讓開發人員進行除錯：
```
  extern "C" void __cxa_pure_virtual()
  {
      ABORE_AND_REPORT_ERROR();
  }
```

基本就這樣，如果還有其它的缺失的話，等我發現再補上。

在嵌入式裝置上使用 C++ 進行開發：概念篇

Sat, 30 Mar 2019 16:26:29 +0800

雖然我比較喜好 C 語言，但從我轉換跑道進入嵌入式開發以來，卻常常壓抑不住想要把 C++ 程式碼放進產品專案裡面的想法！當然我會有這樣的想法是有原因的。

我常想在嵌入式環境上使用 C++ 開發程式，哪怕只是其中一部份的程式碼也好！這個想法常常涌上我的心頭，特別是當我埋首在複雜到快到天上的程式碼中的時候，只是礙於一些行規而遲遲沒有付諸行動，現在想想真是不知道當時在堅持什麼啊！總之，接下來就要分享一些我在這方面上面的想法。而這篇文章也比較偏重關於想法、概念的東西，至於一些技術細節就留待之後再做詳解。

(一些技術細節請參考「在嵌入式裝置上使用 C++ 進行開發：G++ 實做篇」與「C 呼叫 C++ 函式的方法」 )

嵌入式裝置上的困難

在說 C++ 之前，先來了解一下在嵌入式裝置上開發程式到底都有什麼困難？這樣才能清楚的知道我們要面對的是什麼問題。

在一般的 PC 環境上，使用 C++ 開發程式並沒有什麼太多的問題，除非你是要和 Linus Torvalds 共事！但在嵌入式裝置上，由於硬體尺寸、價格、耗電等各種要求使得裝置的硬體資源可能相當拮据，而這成為了幾乎所有開發瓶頸的根本問題來源：

記憶體容量低

以目前來說，業界常見的嵌入式裝置裡能夠使用的記憶體大約在數十 MB 左右，有些特別便宜小巧的單晶片甚至只有數百位元組。因此記憶體的使用錙銖必較，像 Java 這種採用動態記憶體配置和垃圾蒐集機制的怪獸便不太適合使用在這種場合。
儲存空間容量低

不像 PC 一般都把檔案存放在硬碟，嵌入式裝置可以用來儲存資料的裝置通常是像 SPI flash 或 EEPROM 之類，其容量通常約在十來 MB 到數百 KB 之間。這代表你沒有空間亂塞一堆檔案，不能肆無忌憚打上龐大的程式庫，也不能寫太多程式碼，否則編譯出來的程式會大到燒不進去！
運算效能低

目前常見嵌入裝置的 CPU 時脈約在數百 MHz 左右，運算速度不快。我曾經玩過一個時脈大約 200 MHz 的設備，使用 OpenSSL 連接一個網站直到 SSL 交握完成竟然要花費一分多鐘！後來改用其他比較講究效能的程式庫才把連線時間降低到可接受的程度。
軟體環境功能少

比較大型的嵌入式裝置一般使用極度裁剪過的 Linux 核心，所以可能會缺少一些平常覺得很普通的功能，比如說網路功能、檔案系統支援、時區、以及其他平常可能蠻好用的一些工具程式等等。當然這也是為了減少系統體積而做出的刪減需求，但確實在某些時候會讓開發除錯上比較不方便。還有一些裝置連作業系統都放不下，所以什麼功能都要自己來，光是要做出 TCP/IP 網路就可以先折騰好幾個三天三夜！

當然，我上面描述的嵌入式裝置是指大部份可用在商業產品上面的嵌入式裝置，而不是像樹莓派這種擁有超高硬體資源的東西。有些裝置如樹莓派等，雖名曰嵌入式裝置，但其上之作業環境與軟硬體資源已經和一般桌上電腦沒有太多不同，有些裝置甚至連 Windows 10 都可以安裝使用。對於這樣效能強大的裝置，基本上完全沒有必要去糾結 C 和 C++ 的差異，就算想要用 Java 還是 Python 之類的東西來開發應用，我想也都不是什麼問題了！

為什麼一般不喜歡在嵌入式裝置上使用 C++？

在產業界確實一般不常見、或者內規不允許在嵌入式裝置上寫 C++ 程式，大約有幾個原因：

C++ 性能不佳

「C++ 程式通常執行上的效能比 C 差得多、記憶體也用得兇。」

這句話其實既對也不對！反駁的人常常會說 C++ 幾乎完全相容於 C，C 能使用的寫法沒道理在 C++ 沒辦法寫，那麼編譯出來的不管是效能、記憶體使用、或是程式大小等等不應該與 C 有別，只有可能是寫程式的人功力的問題！這些理由是確實的，也是為什麼我可以在嵌入式裝置寫 C++ 的最大原因。

但另一方面，寫 C++ 不就是為了 C++ 一大堆語法上的方便、以及豐富好用的標準程式庫元件比如像是種類眾多的容器嗎？如果我使用 C++ 編譯器，卻寫的全是純 C 的東西，那又何必呢？這樣我直接使用 C 編譯器不是更輕便？因此我也讚同 C++ 在一般的應用場景下會比 C 來的肥又慢這種說法。
業界缺乏熟練 C++ 的專業人員

雖然 C++ 也算歷史悠久、也不是太冷門的語言，但觀察臺灣在需要嵌入式開發的製造業裡面，確實少見熟悉 C++ 與近代程設概念如物件導向和設計模式等的開發人員。這些研發人員多是從電子電機、單晶片程式等一路學過來的人，雖在電子軟硬體方面擁有難以取代的專業知識，卻顯少接受過純軟體知識概念上的教育，導致普遍缺乏比較花俏現代的高階語言和其他軟體技能。在這種環境下，有時並不是 C++ 真的不好，而是如果真的使用了 C++ 的話，會讓一票人難以閱讀理解，後續維護上也會存在困難。
缺乏 C++ 編譯器

有時候無法使用 C++ 並不是什麼其他的問題，而是開發環境就沒有 C++ 編譯器可以使用！嵌入式開發環境千千萬萬種，並不是所有的方案都有 Linux & G++ 方案，或者是 C++ 編譯器是選用工具且價格高，比如說 Keil 的工具等。但是遇到這種狀況其實很好解決，因為你根本就沒有 C++ 可以用，所以就不用糾結了，趕快回去想辦法用好 C 編譯器吧！

為什麼想要在嵌入式裝置上使用 C++

既然 C 語言可用且被廣泛使用，又為何想要在嵌入式裝置上面使用 C++ 程式呢？簡單一句話總結就是現在電子裝置產品功能愈來愈複雜多樣的緣故！

因為產品需求愈來愈豐富多變，產品程式碼也就愈來愈複雜，迫切需要導入物件導向等設計方法才能妥善應付現代商場所需要的變化，而物件導向正是 C 語言的硬傷。當然，並不是無法使用 C 語言寫作物件導向式程式，最經典的案例大概就是 GTK+ 的程式碼，其使用各種技巧，使得以 C 語言實做的 GTK+ 能擁有各種物件導向語言的特性。然而實用層面上，簡單的類別封裝還好處理，我本人一直以來也都使用了這些技巧，可是一碰到多型就完蛋了！ 你看看那些用 C 語言模擬虛函式、模擬繼承、處理父類別轉子類別的轉型方法，只能用一句話來形容，就是複雜又難以維持！

那麼與其用 C 語言來硬生生的模擬這些 C++ 特性 – 特別是多型的特性，不只製做複雜，編寫完後其他人也難以理解維護，反而容易成為蟲子的溫床，這時直接改用 C++ 來寫反而是更好的解決方案，並且效能還更好！畢竟在物件導向特性橫豎都需要的情況下，從應用程式碼手工模擬的方式要怎麼樣才能比從編譯器層面實做來的更好？

雖然討論的是嵌入式領域，但到這裡，我們還是要再進一步的限縮我們所討論的嵌入式裝置範圍。我們要把那些計算資源極度匱乏的裝置排除在外，比如那些記憶容量只有數百到數千位元組的單晶片裝置等。因為在這些裝置上，即便用 C 語言來寫程式也是非常艱困的，也許你更因該考慮在部份的程式碼上使用組合語言。再者使用這種類型硬體的場合多半也不會拿來做什麼太過於複雜的事情，因此沒有需求。而另一個極端，就是那些雖名為嵌入式卻擁有可與 PC 相比之計算能力的裝置，也已被我們早先排除，因為在這種裝置上已經不需要去糾結 C 與 C++ 的差異了！也許你更應該考慮使用 Android + Java！最終，這次主題所聚焦的嵌入式裝置，大約就是那些記憶容量以 MB 計、CPU 時脈約在數百 MHz，可能包含一些週邊設備如網路與串列埠的，常被使用在各種終端設備上的嵌入式裝置。

C++ 有什麼不同？

既然我考慮在通常使用 C 語言的地方使用 C++，那麼就需要去分析 C++ 與 C 相比到底有哪些不同，這樣我們才能清楚到底要解決或迴避哪些問題？因此下面的差異比較將會集中在那些會對於效能與空間造成影響的觀點層面。

首先我們先來看看，那些一般可能感覺上有差，然而實際上無關緊要的部份：

C++ 類別

C++ 的類別(class)其實與 C 的結構(struct)是一模一樣的東西，對於編譯後的結果沒有任何影響。
C++ 成員權限控管

C++ 類別內的權限控管關鍵字如 public、private、和 protected 等，全都是編譯時期由編譯器來過濾的東西，所以依然沒有任何影響。
C++ 成員函式

C++ 類別成員函式實際上也與 C 函式完全一樣，函式對類別的綁定也是編譯時期的工作，不影響編譯後的成品。唯一的不同在於成員函式多了一個參數，用來隱式傳遞物件實體指標，然而使用 C 語言寫的函式也同樣需要傳遞結構指標，所以其實沒有太多差別。
C++ 同名函式重載

C++ 的同名函式重載是在編譯時期由編譯器處理的，編譯後的每個函式其實都會變成名稱不一樣的普通函式，所以沒有任何影響。
C++ 函式參數預設值

C++ 支援的函式參數預設值一樣是編譯時期處理完畢的東西，所以沒有任何影響。
C++ 名稱空間

C++ 的名稱空間亦為編譯時期由編譯器所控管的機制，所以沒有任何影響。

接下來再看看那些實際上真的有些不同，只是其效果不一定造成太大影響的部份：

虛擬函式

虛擬函式主要造成的影響是關於執行效能的部份，虛擬函式的呼叫比起一般函式還多了一個虛擬函式表查詢工作，確實會讓函式的呼叫慢了點。並且因為虛擬函式是執行時期的動態係結函式，所以編譯器可能比較難在這上面去做比較有效的最佳化行為，沒辦法事先進行函式展開、函式呼叫濃縮精減等處理。但如果把必須使用物件導向與多型的程式設計做為前提的話，比起手工自製的基於函式指標的虛擬函式表模擬來說，C++ 原生的機制顯然更有效率且更不易出錯！
類別建構子與解構子

C++ 類別支援建構與解構函式的呼叫，好處是讓人在使用類別的時候，可以少費心在關於物件生命週期的維護上；而壞處就是編譯器會到處在程式碼安插建構和解構呼叫，使得程式碼尺寸些許膨脹。但在絕大部份的應用環境裡，這一點程式碼膨脹通常都應該還是在可接受的範圍內！
類別繼承

C++ 的類別繼承看起來和 C 的結構嵌套是一樣的，但若再加上建構子與解構子的效應那就不一樣了！比如一個擁有十個父類別的類別，那麼它在建構或解構的時候，就可能要呼叫十次的建構或解構函式！當然，一個嵌套了十層的 C 結構很可能也會需要在它的生命週期維護上一層一層去做處理，所以繼承與建構解構所造成的影響通常還是表現在程式碼膨脹上，而非效能表現上。

然而多重繼承的情況會讓上述問題更加惡化，此外還附贈讓程式的行為變得更不穩定而難以預測掌握！後面這部份嚴格上不能說是 C++ 的錯，但是 C++ 那公認超級複雜的繼承相關規則與行為讓編譯器不容易做得妥善。即便拋開編譯器的問題，產業界也少有人能夠完整掌握 C++ 的各種規則和例外，綜合因素使得應用了多重繼承技術的程式碼容易出現一些意料之外的行為，而這又不是嵌入式應用所樂見的！

可是解決的方法也很簡單，不要使用多重繼承就好了！至少到目前為止會複雜到需要動用多重繼承的應用多為 GUI 框架，然而依據不可靠的經驗顯示，能夠大玩特玩 GUI 的裝置基本上硬體資源是相對充足得多的！
運算子重載

C++ 允許運算子重載，這會使得有一些情況下的運算子其實是函式呼叫，效能會差。這嚴格說起來也不能算是運算子重載的錯，因為對於一些本就不單純的操作，就算用 C 來寫大概也免不了需要函式呼叫，使用運算子重載只能算是語法糖而已，並不能算是拉低效能的元兇。

運算子重載真正可怕的地方在於他會隱藏複雜度，使得一些像是 a + b 這種看上去很單純的操作其實可能背後一點也不單純，但它的複雜性卻容易在語法糖的表面下被忽略掉，使得你的程式莫名其妙的慢了下來！

結論是，運算子重載本身在程式編譯結果上並沒有壞的影響，使用得當的話可以讓你的程式更簡單；它的壞處是表現在容易迷惑人心上面，讓你不自覺你的程式其實很複雜，因此請小心使用！

終於來到重頭戲！接下來列舉的就是那些真正成為關鍵因素的重大差異：

模版

模版的使用很容易造成程式碼的膨脹，因為它等於是到處在各個檔案裡進行程式碼展開，尤其是如果 C++ 程式碼裡面使用了標準程式庫裡的各種模版的話，絕對會造成程式碼大量膨脹，因此有必要禁止使用模版相關功能。
C++ 執行時庫

C++ 執行時期程式庫的作用就和 C 執行時庫一樣，用來提供一些程式語言的基楚功能，其實應該沒什麼問題，但差就差在 C++ 執行時庫通常體積龐大！以我曾經手過的一臺機器為例，C++ 的程式庫檔案(libstdc++.so) 就有 4.9 MB 大，而 C 的程式庫檔案(libgcc_s.so) 只有 1.3 MB，因此若能夠移除 C++ 執行時庫的話，會給原來就很拮据的儲存空間帶來大福音！

當然，移除了 C++ 執行時庫就代表了很多 C++ 的原生功能無法使用，比如說標準程式庫的全部功能、以及一些如例外和 RTTI 等 C++ 執行期機制。但是這些功能我們絕大部分可以用 C 標準程式庫的功能、或代用寫法來替代，所以問題不大，只要改變寫作習慣即可。畢竟在導入 C++ 之前，我們已經一直使用 C 相關的習慣用的很嫻熟了不是？
例外機制

C++、以及許多曾借鑑 C++ 的現代程式語言都存在例外拋接這種錯誤傳遞機制，這種機制好用歸好用，但在嵌入式裝置上就會明顯的拖慢程式的效能，並且例外傳遞機制通常需要依賴 C++ 執行時庫的支援。因此需要禁用 C++ 的例外傳遞機制，改用 C 風格的傳統錯誤傳遞機制如 error code 等；最多就是使用 setjmp/longjmp 來模擬，不過要記得在 longjmp 的過程並不會自動解構需要解構的物件！
RTTI

RTTI 是另一個 C++ 的基本功能，它實做了如父類別轉子類別這種時機所需要的型別檢查，但顯然這種執行時期的檢查工作會拖慢程式效能，並且這種機制也會需要依賴 C++ 執行時庫。然而停用 RTTI 機制的副作用不大，動態轉型依然還是可以繼續轉，只是程式不會再幫我們檢查型別，需要依賴程設人員確保這些型態轉換是沒有問題的！
記憶體碎片

C++ 寫出來的程式常頻繁使用 heap 空間，衍生記憶體碎片化的問題，尤其在記憶體資源缺乏的嵌入式裝置上更顯嚴重！

雖然嚴格說起來，這並不是 C++ 的問題，因為你完全可以在 C++ 程式裡按傳統的路子把東西建立在 stack 或 global 空間上，但是寫 C++ 程式若不使用 heap 空間的話，使用 C++ 的意義就低很多很多了；畢竟你會想要在嵌入式裝置上使用 C++，大概九成五就是想要使用 C++ 的多型多態特性是吧？而多型物件若不是建立在 heap 上面的話，雖並不是寫不出來，但你看看那寫出來的各種物件管理工作會長成什麼妖豔的樣子？這就是為什麼我會說 C++ 程式在嵌入式裝置上無法避免記憶體碎片化的問題。

當然緩解這問題的方法也不是沒有的！除了儘量不進行不必要的 heap allocation、和加大記憶體空間之外，也可以透過自行實做 heap 分配邏輯，將不同的記憶體需求配置在不同的記憶體區段上，緩解碎片化的問題。
與 C 程式互相呼叫

既然您在思考在產品裡使用 C++ 的可能性，那通常表示您的產品目前都是使用 C 開發的吧？那麼除非您打算全部翻掉改使用 C++ 重寫(想都知道不可能)，否則一定是想要把一部份的程式碼用 C++ 改寫對吧？這樣就會需要面對 C 程式碼和 C++ 程式碼互相呼叫的問題了。

C++ 呼叫 C 函式通常沒有什麼問題，畢竟 C++ 號稱是 C 的超集；可是反過來，若 C++ 被用來改寫一些底層模組，那上層的 C 程式要怎麼呼叫它們呢？這就會需要去製做一些 wrapper 函式、甚至可能需要建立一些 wrapper 物件！

解決方案總結

最後來簡單整理一下為了在嵌入式裝置上使用 C++ 編寫程式，建議進行哪些修改調整：

儘量減少、或最好不要使用模版的寫法。
不要使用多重繼承與虛擬繼承。
移除 C++ 執行時庫，不要使用 C++ 標準函式庫的功能，改使用 C 標準函式庫或其他程式庫的功能來替代。
關閉編譯器對例外機制的支援，改用 error code 或 setjmp/longjmp 或其他傳統的錯誤傳遞機制。
關閉編譯器對 RTTI 的支援。

概念上就是這樣，然後就可以盡情的使用 C++ 在嵌入式裝置上奔馳了！

其實從另一個角度來解釋也是可以的：我們的整份程式碼、整個專案依然固守著 C 語言的一切，只僅僅取用了 C++ 的類別和多型的特性，好讓一些複雜的部份變得簡單！

我推薦的程式設計命名風格(C&C++)

Mon, 25 Mar 2019 21:00:00 +0800

之前批評了一番從前曾經流行、現在還有很多人在用的匈牙利命名法，後來也介紹了一些當前常見的命名方式，但也許有些人對如何命名這件事還是感到迷盲，這引起了我想要寫下我自己所使用的命名風格的想法，給人參考照路的同時也為我留個筆記。

其實命名這件事博大精深，甚至命名已經不是單純的命名學問，還與程式設計架構、模式等思路息息相關，互相影響。不是我不願意告訴你完整命名的知識，而是全部寫出來的話會是一個蠻大的主題，還要拉上其他相關的程式模式框架介紹，我想足夠寫成一本書了！因此我這次只很簡單的描述說明，在一個識別名稱已經基本思考確定的情況下，我都如何修飾並表現它們的方式。

命名風格有關的變化上，很少有絕對的對與錯，更多的因素是人的「感覺」。正因為如此，不同的命名規則比較和細部變化往往只能靠著不斷嘗試與累積來磨合，所以我也沒辦法說什麼樣的東西是對的，只能告訴你說這是我所喜好的命名方式，您參考看看。

一般變數(local variable)

這裡說的一般變數，就是程式設計中我們會大量定義並使用的、在函式裡面的區域變數，這種變數我絕大部分採用愈簡短愈好的名稱，搭配 Lower Snake Case 風格，例如：buf、data、size、filename、listen_port 等等。

對於一般的區域變數，由於通常擁有良好的上下文關係，加上現在都喜歡寫短函式，在內容不長、變數不多的情況下，自然的變數名稱不需要搞得太複雜，簡單清爽就是最好！

一般函式(C external function)

C 的一般函式名大概是整個命名裡面最長最囉唆的了！沒辦法，因為從大來看，整個模組化程式設計框架下都是以函式做為基本介面單元；從小來看，各種不管靜態還是動態程式庫之間的符號連結也幾乎都是以函式為主，函式的重要性不言而喻，函式同時也成為最容易發生名稱問題的地方！

對於 C 的外部函式(也就是一般的函式)，我採用 Lower Snake Case，並且函式名稱應具有下列格式結構：

程式庫名或模組名_[[父類別名_]類別名_]函式主名

其中若函式不屬於某個類別(意同 C++ 之 class)，則類別名可以省略，父類別亦同；至於程式庫名與模組名在絕大多數的情況下不能省略，只有在這個函式本身屬於最頂層應用程式的函式時，才可以省略不寫。

範例：

ccntr_list_get_first:
即 ccntr 這個程式庫下的 list 這個類別下的 get_first 函式。
ccntr_man_list_iter_get_value:
即 ccntr 這個程式庫下的 man_list 這個類別下的 iter 這個類別下的 get_value 函式。
cts2_get_description:
即 cts2 這個程式庫下的 get_description 函式。

我想熟悉 C++ 的人可能就看懂了，這不就是在仿效 C++ 的 class 和 name space 嗎？沒錯！這些修飾就是在做與 C++ 的 class 和 namespace 相同的名稱空間分割，把 C++ 設計概念的東西搬到 C 語言上來使用。

我所推薦的這個命名方式解決了有關名稱衝突、以及從屬關係不清的問題。但是因為 C 語言沒有 C++ 完整的 namespace 相關機制，只能把這些東西硬塞進函式名稱裡做為函式名稱的一部份，所以函式的名稱很容易變很長，而這也是為什麼 C 語言的程式碼裡面超級喜歡縮寫的原因之一！

另外要注意的一點是：不是只有程式庫公開的函式才應該要採用這個命名， 凡會導出符號名稱到目的檔、靜態程式庫檔、或動態程式庫檔的函式， 也就是所有非 static 的一般 C 函式，都應該要採用這個命名規則！

私有函式(C static function)

C 的 static function 比照一般函式使用 Lower Snake Case 命名，但因為其只能在所屬的程式碼檔案內被使用，也不會匯出符號，所以基本上無需採用一般函式那樣囉唆的命名，直接將主名稱做為整個函式的名稱即可！除非你的一份 C 程式檔案裡面含有兩個以上的類別或模組的程式碼！

函式參數

我的函式參數命名風格比照一般區域變數，採用 Lower Snake Case。並且如果這個函式是所屬一個類別的函式的話， 做為物件實體參考的指標參數應該為函式的第一個參數，以與 C++ 的慣例相同，最好這個參數的名稱要被命名為 self，以類比 C++ 的 this。範例如：

void ccntr_list_link(ccntr_list_t *self, ccntr_list_node_t *pos, ccntr_list_node_t *node);

結構(structure/union)

由於聯合(union)和結構(structure)除了程式上的效果不一樣以外，在語法上的表現是相同的，因此共用同一套命名規則，以下將以結構為主進行說明。

結構成員

結構成員與一般區域變數相似，通常結構體定義都擁有良好的群組分類關係，所以成員名稱並不需要太複雜，命名採簡潔、易懂用途為中心思想，搭配 Lower Snake Case 風格。

結構本身

結構本身命名採用 Lower Snake Case 風格，並需符合下列敘述的規則。

對定義在公開標頭檔的結構話，其名稱需符合下列格式結構：

程式庫名或模組名_結構主名

例如：

cts2_conf:
表示它是 cts2 程式庫下的 conf 資料類型，裡面可能放的都是與 cts2 程式庫有關的配置參數。

程式庫名前綴和模組名前綴可在下列幾種情況下省略：

這個結構被定義在私有標頭檔、或單一模組的程式碼檔裡。
這個結構被定義在函式內、或 C++ 的類別內、或 C++ 的 namespace 內時。

若這個結構被用作為某個類別型態使用的話，其結構主名即同類別名，名稱表示與類別函式相似，但最後需加上 _t 結尾，整體名稱格式如下：

程式庫名或模組名_[父類別名_]類別名_t

例如：

ccntr_man_list_iter_t:
該結構實際表達這是 ccntr 程式庫下的 man_list 類別下的 iter 類別。

結構別名(type define)

有時我們會喜歡用 typedef 給結構取別名，這通常是源自於 C 那煩瑣的變數宣告要求。例如說我有一個結構叫 mytype，則宣告變數時我需要這樣寫：

struct mytype value;

此時，有些人會使用 typedef 為結構取別名：

typedef struct mytype mytype;

這樣，在宣告變數時就可以省略那個 struct：

mytype value;

對於要不要給結構取別名這件事我還沒有確定的判斷。目前的建議是： 如果你設計這個結構是希望用戶把他當一個黑盒子來用的話， 那就應該用別名的方式讓使用者省去那個 struct 字樣，畢竟這時候，這個東西對於用戶來講就是一個不知是什麼東西的型態而已；而另一方面，設計者應該也不希望用戶花太多注意力來關注這個型態到底內部是個什麼東西！通常絕大部份的類別定義屬於這種條件，設計者通常不希望用戶直接操作其成員變數，因此對於絕大部份被當類別使用的結構，我們應該為其設定別名。

相反的， 如果這個結構的設計就是為了要叫使用者直接操作成員變數的話， 何不就大方的告訴大家這是個結構！ 因此建議就比較傾向不設定別名的做法，例如 C 標準函式庫、以及 POSIX API 定義的許多結構就採用這種做法。

巨集(macro)

所有的巨集定義都應在名稱前面加上程式庫或模組名稱，並且應採用 Upper Snake Case 風格，例如：

#define CCNTR_MAN_MAP_ENABLED

只有在單一程式碼檔案內被定義並被使用的巨集可以省略程式庫名稱前綴。

熟悉 C/C++ 的人都應該了解巨集的威力，不論是好的方面還是壞的方面，因此長久以來程式設計圈就有一個不成文的共識，要求使用全大寫來命名所有的巨集。對於熟悉西方語言的人會知道，大寫在文字中具有強調的效果，而全大寫表示的文字一定是很重要或很特別的部份。

列舉(enumerate)

所有的列舉值都應在名稱前面加上程式庫或模組名稱，並且應採用 Upper Snake Case 風格。在模組名稱後面、最好再加上列舉用途名稱，好在程式庫內定義了兩個以上的列舉型態時，可以方便的區分某個列舉值是屬於哪一種用途使用。至於列舉型態本身，則比照結構(structure)的命名規則。例如：

enum mylib_result_code
{
    MYLIB_RC_SUCCESS,
    MYLIB_RC_UNKNOWN_FAILURE,
    MYLIB_RC_CANNOT_ALLOC_MEMORY,
    MYLIB_RC_FILE_NOT_EXIST,
};

列舉值的程式庫名稱前綴、以及用途前綴只有在以下幾種情況下可以被省略：

該列舉在私有標頭檔、或單一程式碼檔案內被定義並被使用。
該列舉被定義在 C++ 的類別內、或 C++ 的 namespace 內。
該列舉是使用 C++11 的 enum class 來定義的。

對列舉值的命名要求比較嚴格有幾個原因：

傳統上的列舉值與結構或聯合等型態的成員不同，其可見域並不受列舉型態的約束。
列舉常被用來定義常數，而巨集也常被用來定義常數，兩者間的用途有所重疊，其可見範圍不受約束的特性也有所相似，因此命名也就互相比照。

C++ 函式

C++ 函式我一般使用 Upper Camel Case 命名風格。當名稱中出現一些平常會寫成大寫的縮寫字時，請把首字母以外的部份寫成小寫，例如一個函式應被命名為 AesEncrypt 而不應被命名為 AESEncrypt。

邏輯上的理由我自己也沒有整理出來，可能這就是一種喜好吧！不知怎地，C++ 函式用 camel case 看起來就是比較搭配！

C 函式必須把很多從屬關係寫進名稱中，導致名稱較長，如果不使用一些區隔性比較強烈的分隔符號來隔離單字的話，可能視覺上容易把他們混淆在一起吧。 C++ 因為擁有 namespace 和真正的 class 來做這些事情，所以不需要這些囉唆的前綴，直接把函式主名當作全名即可。至於 C++ 中不是類別成員的一般函式亦比照辦理， C++ 中的一般函式多半是私有函式，就算要放到標頭檔裡，也有 namespace 可以使用，因此比較沒有名稱衝突和從屬關係不清的問題；而且，若在同一個 C++ 程式碼檔案內，使用不同命名風格來命名函式的話，不會很不統一嗎？

C++ 函式參數

C++ 函式參數比照區域變數以及 C 函式參數，使用 Lower Snake Case 命名風格。

C++ 類別(class)

C++ 類別採用 Upper Camel Case 命名風格，例如：String、FileList 等等。一般情況下不需要額外的前綴後綴，需要的話通常使用 namespace 來處理即可。當名稱中出現一些平常會寫成大寫的縮寫字時，請把首字母以外的部份寫成小寫，例如一個類別應被命名為 AviReader 而不應被命名為 AVIReader。

通常我無需考慮 C++ 類在程式庫間的相容性問題，因為 C++ 那複雜又不統一的函式名稱變換(mangling)、類別生命週期操作、和例外傳遞機制的差異性，已經使得一般情況的 C++ 類別(這裡不是指那些特別被設計來做為程式庫介面使用的純虛類別) 不可能被用作程式庫的介面。我也不擔心類別名和變數名的衝突或混淆，因為所有的變數我都已經使用 lower case 命名了！

名稱空間(namespace)

老實說，這是我個人目前命名方案裡最後一塊未拼上的拼圖！除了我不會使用帶底線的 Snake Case 風格外，目前都有嘗試把 Lower Case 和 Upper Camel Case 用在 namespace 上，尚未探索出最適合的命名方式。

幾種在程式設計中常見的命名風格

Thu, 21 Mar 2019 21:41:19 +0800

在程式設計中，存在大量的命名需求。我們常常需要為大量的自訂元素命名，小從變數、函式，大至模組、程式庫，除了「一個東西究竟要叫什麼名字好？」這個問題常常困擾著具有一定素養的程式設計人員外，「一個名稱該如何呈獻」的問題也常讓程式人員，特別是那些經驗資歷尚淺的人迷惑。

為什麼要有這麼多不同的名稱呈獻方式(風格)？

當我們為一個東西命名，比方說想要給一個變數 “my crazy magic box” 這個名稱，在程式語言裡我卻不能就直接這樣子寫。一個名稱往往使用了超過一個的單字組成，然後用空白來分隔它們；然而空白已經被絕大多數的程式語言用作語法的分隔，再拿來做為識別字的一部份的話，一定會造成語法解析上的障礙，所以絕大部分的程式語言並不允許一個識別字裡面含有空白、以及其他一些特殊符號。

因此我們必須另闢蹊徑，使用其他方法來在視覺上區別一個名稱內的個別元素，既然區別名稱元素的方法不只一個，自然的就造成許多源自不同的發想點而產生的不同名稱方案。不同名稱方案間的差別通常在於美感、喜好、文化等方面，因此誰也沒能統一誰，最後人們通常會在他覺得適合的地方使用不同的命名習慣。

常見的命名風格

由於世界上的命名方案之多，我不可能全部列舉解釋，所以接下來將只介紹一些比較常見而流行的命名風格。

Upper Case/Lower Case

這種命名方案實為兩種相似的方案：
- Upper Case
  
  規則：整個名稱全部使用大寫，並且單字間不做任何區隔。
  範例：MYCRAZYMAGICBOX
- Lower Case
  
  規則：整個名稱全部使用小寫，並且單字間不做任何區隔。
  範例：mycrezymagicbox
這種方案的好處是簡單不費事、需要打的字少；壞處則是單字間少了任何形式的視覺分隔，容易導致一眼看上去不知道在寫什麼？如果你覺得我上面的範例不足以體現這點的話，請試試這個：grepwithsedandawk。

然而它的缺點也不是嚴重到無法踰越。對於通常由兩個以下常用單字所組成的名稱中，熟悉自然語言的人往往可以用極快的速度區別名稱中的單字，例如 totalsize 和 username 等。因此在實際上，這種命名方式仍被大量使用。
Camel Case

這種命名方案又被細分為兩種子型：
- Upper Camel Case/Pascal Case
  
  規則：單字間沒有分隔，每個單字的首字母為大寫、其它為小寫。
  範例：MyCrazyMagicBox
- Lower Camel Case
  
  規則：與 Upper Camel Case 相同，但第一個單字的首字母為小寫。
  範例：myCrazyMagicBox
符合這種規則的名稱在視覺效果上型似駱駝的駝峰，因而得名。

這些方案的好處是名稱間的單字可以被明顯的識別，並且不會導致名稱變長；缺點之一是當名稱中含有專有名詞縮寫時可能會導致迷惑和分歧，例如 “set DB name” 究竟要變成 SetDBName 好？還是 SetDbName 好？
Snake Case

這種命名方案又被細分為兩種子型：
- Upper Snake Case
  
  規則：整個名稱全部使用大寫，單字間以底線 “_” 做為區隔。
  範例：MY_CRAZY_MAGIC_BOX
- Lower Snake Case
  
  規則：整個名稱全部使用小寫，單字間以底線 “_” 做為區隔。
  範例：my_crezy_magic_box
符合這種規則的名稱在視覺效果上型似鈕動的蛇，因而得名。這些方案的好處是名稱間的單字可以被明顯的識別；缺點是會讓名稱變長，這在程式碼橫幅版面空間有限的條件下很難被忽略！

實務上，Snake Case 命名方案常常會和 Upper Case 方案或 Lower Case 方案混用，例如 “set max num” 可能會被表示為 set_maxnum 而不是 set_max_num，這是因為試圖要節省名稱長度的關係導致。
Kebab Case

規則：整個名稱全部使用小寫，單字間以連字號 “-” 做為區隔。
範例：my-crazy-magic-box

符合這種規則的名稱在視覺效果上型似插滿肉的烤肉串，因而得名。

這種命名方案的大部份特性和 Snake Case 相同，除了單字間的連字號比起底線在視覺效果上看起來比較不那麼強烈，所以也受人喜愛。然而大部份的程式語言並不允許連字號(與減號相同)出現在識別字中，因此 Kebab Case 通常只被使用在各種配置文件、資料字串、和支援連字號的少部份程式語言的識別字中。
Hungarian Notation

規則：整個名稱比照 Upper Camel Case，然後在名稱前面再加上全部為小寫的型態縮寫。
範例：bxstMyCrazyMagicBox

這種命名方式即是惡名昭彰的匈牙利命名法！看到它在名稱加上型態縮寫，就可以知道這種命名風格是專為程式「變數」而設計，所以可能難以拿來為函式、類別等變數以外的東西命名。

雖然當今通常不推薦使用匈牙利命名，但對於這麼有名氣而且現在仍常看見的命名風格，打著介紹命名風格的文章又怎能不介紹它呢？有關於匈牙利命名的更多詳細資訊、特別是那些惡形惡狀，請參考我曾發佈的文章：「為什麼不要使用匈牙利命名法？」。

Reference

為什麼不要使用匈牙利命名法？

Sun, 17 Mar 2019 01:11:00 +0800

這篇文章並不完全是我的原創，文章的原始主體來自於 PTT 上相關主題討論的對話節錄，重新編排修飾後又加入了一些我自己的觀點整理而成。

什麼是匈牙利命名法？

匈牙利命名法是一種在程式設計中使用在各種變數的命名上的規則，因這種命名的名稱形似匈牙利人名而得其名(雖然我怎麼看都看不出來到底哪裡像了)。匈牙利命名要求所有的變數名稱需要在前面加上幾個簡短的小寫字母，用以標示該變數的型別。列舉幾個範例如： iIndex 表示它是一個整數、 fSpeed 表示它是一個浮點數、 cSex 表示它是一個字元、 sName 表示它是一個字串、 szName 表示它是一個以零結尾的字串、 pszName 表示它是一個指標，指向一個字串、 lpszName 表示它是一個遠指標，指向一個字串、 g_lpszName 表示它是一個遠指標，指向一個字串，而且這是個全域變數、 a_crszkvc30LastNameCol 啊！我也不知道它的型態是什麼……

為什麼匈牙利命名法不受喜愛？

匈牙利命名法多很多綴字，又不好看又不好記打起來又麻煩，在現代 IDE 輔助下，實用性並不高。舉例，有個變數 Var 型態是 Long Pointer to a Zero-terminated String，那你就必須在變數名稱前面加上 lpsz，變成 lpszVar，凡是遇到 long pointer 變數，命名一律必須前綴 LP，於是傳統採用匈牙利命名的 Win32 SDK 程式中到處都充滿 LP。 Handle of WiNDow 這個型別，就必須命名為 HWND，這類變數有時得前綴 hwnd，這樣很難記又沒意義，又降低可讀性，在現代的程式已經沒有實用價值了。

匈牙利命名法最大的缺點是，現今它沒有任何基於必要性的優點，以至於它所有缺點的負分加起來，就差不多是它的總得分。

匈牙利命名法的優點

變數的型別是什麼，從變數的定義就看得出來了，何必要把型別縮寫加在變數上呢？可能需要它的理由是：

找不到變數定義

如全域變數，不知道它被定義在哪一個檔案，又沒有 IDE 的時候。
懶得找變數定義

對於一個千百行的函式，你不會想中途看到一半，時常要 scroll 到前面去看變數定義，尤其是 C 程式。
猜不到變數型別是什麼

以前的變數命名比較短，如 kn，猜都猜不出來可能的型別是什麼。

匈牙利命名法的優點為什麼不復存在？

然而，環境不一樣了。現在的程式寫作習慣改變了，尤其是 C++ 或說物件導向的程式寫作。

容易知道變數被定義在哪裏

物件導向程式寫作有一個重要的認知是：物必有主。一個變數一定會有個主。 global 變數不被鼓勵使用，而以 class static member 取代之，你很容易知道他被定義在哪裏。
變數定義就在旁邊而已，不必你找

小函式的使用被鼓勵，對於一個 20 行內的函式，你絕對看得到變數定義。對於大一點的函式， C++ (以及 C99 以後的 C)可以讓你在變數使用的前一刻宣告即可，這種寫作方式也被鼓勵。對於一個不認識的變數，它的定義就在前幾行而已。
猜得到變數型別是什麼

完整的變數命名被鼓勵，加上物件導向的特性，很容易猜得出變數型別。如視窗 window.height 會是一個 unsigned int。 man.height 大概就是一個 float 了。

再加上近代軟體開發工具的進步，補足了匈牙利命名法被需要的條件，所以基本上，匈牙利命名法在現在已經沒有任何基於必要性的優點了。

匈牙利命名法的缺點

好煩！

我已經知道這個變數是 int 了，為什麼程式碼到處都在說它是 int 。
不清爽！

vector.x 不是很好嗎，為什麼要寫 vVector.fx。
變數改型別的時候怎麼辦？

變數改變型別是有可能的，如果一個變數分佈在 20 個檔案，最起碼要改 20 次。當然，有好的開發環境可能會方便一點；但如果是發佈給人家用的 API 呢，改變型別縮寫，鐵定會被客戶抱怨一下。
五技而窮！

基於物件導向，以及程式規模愈來愈大，大量的自定型別被定義，如何去為這些型別找個容易識別的縮寫呢？
未能適用於函式名稱！

以理類推，函式前面也要加回傳型別的縮寫呀，這樣才統一呀！如果變數前面要加型別縮寫才行，那為什麼有回傳值的函式不用，總是要平等對待呀。如 fsqrt()、man.fGetHeight()、vBeep()。天阿！應該沒有人會這樣子用。一個無法貫徹於各種情況的風格，可能不是一個好的風格。
難以為多型物件命名！

如下，應該是這樣好？
```
 Man* mnRenderer = new Programmer;
```
還是這樣好？
```
 Man* pgmRenderer = new Programmer;
```
在物件導向程式寫作裏，一個變數的角色與行為，會比它的型別來得重要。

無法用於泛型程式寫作！

如：

 template<class TYPE> class Vector
 {
 public:
     TYPE x;
     TYPE y;
     TYPE z;
 };

這裏的 x,y,z 前面要加什麼縮寫好？

另外，像是 g_XXX、m_XXX 等也是沒有必要的

g_XXX:

程式裏不太應該要有 global 變數，放到 class static member，g_ 就用不上了。如 Man::Count，你一定知道它是一個唯一的變數。
m_XXX:

m_XXX 也是沒有必要的，如：
```
  vector.m_x;
```
m_ 是個贅字，"." (或者 “->”) 本身就說出 x 是它的 member 了。另外：
```
  Vector& Vector::operator = (const Vector& b)
  {
      this->x = b.x;
      this->y = b.y;
      this->z = b.z;

      return *this;
  }
```
是比下面的寫法來得簡明的：
```
  Vector& Vector::operator = (const Vector& b)
  {
      m_x = b.m_x;
      m_y = b.m_y;
      m_z = b.m_z;

      return *this;
  }
```
m_ 唯一有用的地方是在 member function 裡，然而加 this-> 就好了。 this-> 是語言提供的本尊原生寫法，另立主張，有人喜歡，有人不喜歡，這樣就不好了。

另外，應該讓 class 的使用者使用乾淨的介面， vector.m_x，其實是多給使用者麻煩。考慮使用者的方便，會比讓自己方便來得重要。

匈牙利命名法並不能幫助理解

「如果不知道變數的意義，就算知道它的型別也沒用的！」

嚴格來說，這並不能算上是匈牙利命名法的缺點，只能視為一個對使用匈牙利命名的人可能走入歧途的提醒。

匈牙利命名並不是提升閱讀性的解決方案，對於理解程式碼也沒有幫助。他雖然讓你知道一個變數的型別，但若主名稱本身意義不明，比如說 fAaa，你一樣無法知道這是一個什麼東西？

因此有另一些人認為，程式人員應該良好的命名變數，而不是妄想用匈牙利命名修飾來解決一切。妥善的變數名稱(主名)可以讓人一看就明白它的意義與用途，而這通常會比變數是什麼型態還要重要！有一些時候，良好命名的變數甚至可以直覺的表達它的型別，比方說看到 WindSpeed 應就知道它會是一個浮點數、 TryCount 就是一個整數、而 IsOpened 應就是布林值。

匈牙利命名法的時代背景

既然匈牙利命名法看來只有一卡車的缺點而沒有任何在現代必要的優點，那麼為什麼這種命名法可以流行在程式設計領域呢？這就需要了解一下匈牙利命名法誕生那個年代的一些背景。

在古時候的程式設計領域，還沒有像現代 IDE 等的方便工具，也缺少現代已經稀鬆平常的一些如語法變色、自動完成、語法檢查、宣告與定義的分析搜尋、和編輯器內的查找與跳轉等等的功能。再加上當時硬體和軟體上的技術限制，變數等符號能使用的名稱長度極為有限；大家也不喜歡做太多層的函式呼叫，這使得內容很長的函式相當常見(這是手工最佳化的一部份)。所以在那個時代流行一些試圖增加程式閱讀性和減少人為出錯的小技巧，其中就包括了著名的匈牙利命名法。

另一方面，模版、泛型編程還沒被發明，物件導向與多型等程式設計概念還未出現，使得匈牙利命名的許多缺點並不明顯。這全部的條件造就了讓匈牙利命名被需要的環境，使得其曾經大為流行。

匈牙利命名法的現況

雖然軟硬體環境的推進使得需要匈牙利命名的情景不再，但是工程人員的習慣已經養成，對於那些已經用了半輩子匈牙利命名的人，他們總還是習慣繼續使用匈牙利命名。

在某些地方，匈牙利命名法可能被推崇為「嚴謹的命名方案」，並繼續這樣的教育新的程設人員，使得很多不明所以的新進人員以為使用這種命名法看起來比較專業，而不明所以的公司研發單位會將其寫入設計風格規範中。這些導致了雖然匈牙利命名法已無必要且缺點不少，但仍大量出現於產業界的程式碼中的狀況。

另外，雖然匈牙利命名法常見於 C/C++ 程式，然而匈牙利命名法並不是只能用在 C/C++ 上， C/C++ 的各種規範中也未曾要求或推薦使用匈牙利命名法。只是因為匈牙利命名法被發明並流行的時代剛好就是 C/C++ 流行的時代，而在更新的程式語言出現的時候，已經不再推崇匈牙利命名了，所以不常在 C/C++ 以外的地方被看見。這可能導致了某些人會把 C/C++ 和匈牙利命名法連結在一起，然而實際上並不是這樣。

為什麼不要使用全域變數？

Sun, 17 Mar 2019 01:10:00 +0800

這篇文章並不完全是我的原創，文章的原始主體來自於程式設計俱樂部上相關主題討論的對話節錄，重新編排修飾後又加入了一些我自己的觀點整理而成。

什麼是全域變數？

全域變數(Global Variable)是一種在較老的程式語言中廣泛被支援的一種特別的變數類型，這種變數可以在任何時候被整個程式的任何一段程式碼引用、修改，而它的生命週期也橫跨了整個程式的生命期。在記憶體資源極度缺乏的時代，函式參數傳遞機制和自訂資料結構使用受限，全域變數可能是整個程式內部傳遞資料所必須且高效的手段。因此全域變數常見於那些由比較年長的程式語言，如 Fortran、C、C++ 等，所寫作的程式碼。

到了現代，隨著程式開發愈發複雜，全域變數的缺點更顯突出；加上硬體資源的擴展，以及新的軟體設計架構如物件導向程式設計等被提出，全域變數的使用必要性不再。因此許多新一代的程式語言如 Java 等，甚至就直接移除對全域變數的語法支援！

全域變數的缺點

變數值追蹤困難

全域變數的值可以在整個程式的任何地方被更改掉。任何一個只要有使用到這個全域變數的程式碼都有可能對其值進行修改，並且通常很難整理出全域變數在大程式裡面的工作流程與變動關係，造成開發除錯上的困難！
全域變數不易接受開發上的修改變動

如果你更改了全域變數的使用方式，你必須去檢查每一個用到全域變數的函式，做出適當的修改；況且通常你還得注意這些全域數值被修改的時機和順序！這些增加了程式維護上的難度，也阻礙了程式在日後擴充的道路。
程式碼不易閱讀理解

使用函數參數傳遞變數的好處是，你可以一眼看出一個函式被呼叫執行時需要參考什麼資料、又可預期什麼資料可能會被改變，因為這些資料都展示在函式的傳入、傳出參數或傳回值上。

相反的，一眼看向函式的呼叫時，無法知道這函式將會改變哪些全域變數？實際上你得實際查閱函式的內容，並且層層深入更下層的函式，才有可能明白會受到這個函式影響的全域變數們；或者你也可以查閱函式的使用說明文件，如果這個函式有文件而且還沒與現實脫節的話…… 如果函式多呼叫幾層，而每一層可能都會參考或改變一些全域變數的話，可想而知整個程式的行為會非常隱晦不明，使得難以閱讀、難以理解！
函式或模組將不能被獨立使用

如果你的函式用了全域變數，那這的函式就不能獨立使用，你無法簡單的把函式(或整個模組)抽出來用在其它的地方。

因為這個模組依賴了這個可能實體被藏在其他模組的全域變數，導致你必須要連同其他模組一起使用，而不能單獨的將一個模組抽出來另做他用。你不一定能夠透過連結一個代位的全域變數來解決模組之間基於全域變數的連結，除非能夠搞清楚並模擬出這個全域變數在執行期應該要有的行為。

這些條件降低了程式碼的重用性、組合性、移植性、和可測試性，同時還提高了模組間的偶合性！
全域變數的設計與物件導向概念格格不入

一個模組一旦設計了全域變數，則這個模組將不能夠產生兩個以上的實體，立刻限制了模組複用的可能性。

物件導向的重要精神之一就是每個物件擁有屬於自己的獨立狀態，而全域變數打破了這點！撇開比較高深的名詞術語，我用較為通俗的例子來問這個問題：「你能夠試著儘量全部使用全域變數來設計製做一個像 std::string 這樣的功能模組嗎？」如果你真的嘗試去做的話，請再試著在你的測試程式中建立 5 個 string 實體，然後同時、或交互的使用它們並觀察結果。

全域變數具有的獨有性和唯一性，使得一個模組一旦使用了全域變數做為狀態儲存，則十之八九可肯定它將與物件無緣。

合理使用全域變數的時機

雖然全域變數的缺點一籮筐，甚至導致比 C++ 還新的程式語言紛紛拋棄全域變數這種大怪獸！但以 C/C++ 程式設計來說，還是有些時候必須使用全域變數，甚至使用全域變數會更好。可是相信我，在絕大部分的情況下你不應該設計全域變數，而且絕大部份產業界程式碼裡見到的全域變數其實都有不使用全域變數的、更優雅的寫法！

少數可以合理使用全域變數的時機列舉如下：

「常數」，也就是在程式的整個生命週期內不會進行任何更動的資料。

這些資料常見如數學上的 PI、或是某種資料常數表格如加密對照表、影像調色盤顏色表等等，在需要使用它們的時候才建立物件、然後填寫資料的做法不僅囉唆，而且效率較低。既然這些資料是固定不動的，就不存在「是誰什麼時候在哪裡改了資料」這樣的變數追蹤困難，這時讓大家在程式各處參照使用同一個物件就是一種聰明的設計！
「獨體」 設計模式裡的引用計數器。

在獨體設計模式裡，至少必須存在一個唯一的物件引用計數器，因此無法避免的必須使用生命週期足夠長、而且所有物件都可以參照使用的全域變數。事實上在這種狀況下，要討論的可能是獨體設計在該環境下是否合理？是否該物件所使用的資源真的為系統中的唯一、並且具有獨占性？至於若採用了獨體的設計，則全域變數的使用就成為必然！

全域變數的補救措施(以 C/C++ 為例)

有時候程式裡就是會有全域變數，不論是因為前述的合理使用、還是因為老程式碼既成的結果，尤其在後者的狀況下如果要試圖消滅程式碼中的全域變數，往往會帶來翻天覆地的程式翻修，以及連帶的程式不穩定、和測試工作量的暴增！其實不管是要改善既成程式中全域變數、還是在上述合理範圍內即將加入的全域變數，在擺脫不了全域變數的前提下，還是有一些小技巧可以稍稍減輕全域變數對整份程式碼造成的破壞力的！

縮減全域變數的可視範圍

縮小全域變數的可見範圍也就縮小了它的影響範圍、就減小了複雜度。所以：
1. 只有一個函式需要參照的全域變數就應該在函式裡宣告為 static 變數；
2. 只有一個程式碼檔(*.c 或 *.cpp)內部需要使用的全域變數就不要定義在標頭檔(*.h 或 *.hpp)；
3. 沒有要給其他模組參照使用的全域變數就加上 static 修飾；
4. 在獨體設計中，若使用的是 C++ 的話，請儘量使用 class static member variable 定義引用計數，而不要使用定義在 class 外面的全域變數。
使用嚴謹的命名方案

對於暴露在外的全域變數，特別是整份程式碼都可以參照的全域變數，我們應使用比較嚴謹複雜的命名方案來解決一些問題，寧可讓全域變數的名稱變得比較長、比較難寫，誰叫它是全域變數呢！

因缺乏上下文關係，而導致變數意含難明，所以我們應該把名稱定的更能清楚表達其作用與意義，像是 student_count 的名稱就比 stdcnt 來得好；至於名為 aa 這樣的全域變數根本就是故意搞亂其他工程師，讓程式更容易產生 bug 用的！

因為在上層使用環境中可能還存在其它的程式庫、甚至是上層使用者自己寫的程式碼，為了避免名稱衝突，暴露在模組外的全域變數應加上模組名稱做為前綴， MYMODULE_TANK_MAX_VOLUME 的名稱就比 TANK_MAX_VOLUME 來得妥當；至於 MAX_VOLUME 的名稱應被禁止，因為它太可能和其他的程式庫或上層使用者產生名稱衝突，比如說一般記錄音量最大值的變數通常也可以叫作 MAX_VOLUME！而反過來看亦同。

以上改善全域變數的做法很有限、效果也很有限，沒辦法，全域變數就是這樣討厭！所以正途還是要避免全域變數的使用才對！

使用盜版軟體到底是誰得了益？

Thu, 14 Mar 2019 23:35:21 +0800

東亞地區軟體盜版猖獗，使用盜版軟體的心態除了不願意花錢買軟體之外，多半還帶有一絲竊喜，覺得好像得到了便宜！甚至中國大陸還流傳一句話：「我們的軟體授權費，早在清朝，慈禧太后就付過了！」然而，真的是這樣嗎？在整個盜版風氣底下，真正受害的是誰？而又是誰真正搜刮了所有的利益呢？

學生時代我和同齡的同學們用的基本上全都是盜版軟體，這當中當然有許多原因，除了軟體很貴沒錢買、不知道有不用錢的正版軟體存在等因素之外，心理層面上，使用盜版軟體也是反擊這個社會、反擊正版價錢不合理的高(至少消費者是這樣認為的)的手段；而且反正大家都這樣，如果政府敢抓盜版的話就是政府的錯 ^[1] ！

也因為大家都習以為常了，所以不覺得這樣做有什麼不對？甚至在好長的一段時間裡，使用正版軟體的人還會被恥笑！當我們使用盜版軟體的時候還會暗自竊喜，覺得得到了好處，可以不用付錢而依然享受軟體的功能。到後來甚至有些人覺得軟體公司有義務降低售價、或免費提供給像是學生老師等這樣的族群使用，如果政府嘰嘰喳喳的話、如果廠商要強迫我付錢的話，我們就成立「反反盜版」聯盟大聲的罵他們 ^[2] ^[3] ^[4] ^[5] ！

結果呢？二十多年了，那些軟體大廠有被我們給罵倒嗎？或是因為我們的不滿而降價嗎？反而我們卻愈陷愈深，愈來愈離不開他們的產品！

為什麼會這樣呢？原因很簡單，就是競爭！我試著用一個很簡單的例子來說明，假設你是一間公司的老闆，而你們公司生產的產品是很多客戶所需要的，並且因為沒有別家公司和你競爭，所以你的客戶只會、也只能買你的產品，那麼，你會為你的產品訂多少價錢呢？當客戶來和你討價還價的時候，你會給他折扣嗎？然後把狀況反過來，當有很多老闆都生產和你相同用途的產品，而且價錢還差不多，那當你面對上面情境的時候，你又會如何做決定呢？

了解了上面的原理後，再來看看為什麼這些軟體大廠的產品都沒有競爭者(我是指有能力可以影響市場的)？當然商場上造成此消彼長的因素很多，卻也不能忽視盜版的影響佔比夠大！任何商品的開發成熟都需要時間，軟體也是。就以大家可能常用的 MS Office 為例，很多人折服於它強大的功能；但你知道早期的 Office，比如說 Excel，被視為功能虛弱的產品嗎？你知道那個時候大多使用 Lotus 1-2-3 而不願意使用 Excel 嗎？還好微軟還有其他產品線支持，才讓整個 Office 能夠支撐到足夠完善到大家願意去使用的時候。

好的，那麼如果現在一間公司，比如說一間本地的小公司，推出了文書軟體，請問您願意使用嗎？雖然這個軟體尚不健全，功能還不完整，甚至可能存在一些錯誤；可是看看 MS Office 上萬的價格，再對比這個新軟體可能才幾個千的價錢，就先湊合著用吧！於是這家小公司可以慢慢發展茁壯，他的產品也許會愈來愈完善，終有一天可以在文書處理市場，或至少在本地的市場上佔有一定影響力，到時 MS Office 不降價競爭也不容易！

但是，這個故事完全忽略了盜版的問題！現在可好，兩個軟體擺在你面前通通不用錢(盜版因素)，請問您選哪個？於是真實的狀況是小公司無法崛起，而在沒有競爭者的情況下，市場上僅剩的軟體公司擁有絕對的話語權！ 最後，盜版真正打擊的不是那些軟體大廠，在盜版風氣下直接趴下的正是本地的軟體產業！

再來，既然有了盜版，我們就來看看有關抓盜版的事情。很多人可能用了半輩子的盜版，卻從沒有被抓過一回！然而廠商們真的不知道你在用盜版嗎？尤其在某些廠商本身還身兼系統軟體發行商的情況下？除了少部份的真正小廠是真的無力抓盜版之外，許多都是在軟體大廠默許之下刻意不做為，好放長線釣大魚！曾經和待過某些公司的資深同事交談過，他透露說那些軟體公司(比如說那些又小又不硬派的) 對於個體戶都睜隻眼閉隻眼，他們的目光都放在企業用戶上；但即便是這樣，對於那些告下去可能會賠到倒閉的小企業通常也是輕輕放下，除非那間公司是他們殺雞儆猴的對象！這就是為什麼他們對於政府單位使用盜版一定追究到底的原因，就因為政府有底氣賠。你說他這個不管那個放過，那真正能夠正常收錢的不就太少了嗎？ 我想這大概就是為什麼軟體大廠的軟體都貴到嚇死人的原因了吧！

至於那些企業用戶其實也很可憐！大企業被迫花天價來買軟體；中小企業沒辦法一次買足授權的話，就只好每年上貢一些軟體稅(保護費)給那些軟體商。你說為什麼這些公司的老闆一定要買這些軟體呢？其實他們沒有選擇！一來是前面解釋過的，有能力抗衡的對手軟體基本不存在。再來是就算你打算將就一下使用比較陽春的替代軟體，你找得到員工嗎？ 比如說以美編常用的 Adobe 系列軟體為例，如果老闆想改採用 GIMP 或 Inkscape，請問目前就業市場有多少求職者會這些軟體？那麼要不就是以更優渥的條件去吸引那些少數會用的高手，要不就是在公司裡訓練，但不論哪一種都是很高的成本，因此老闆掂量一下後，可能就還是咬牙和 Adobe 買軟體了！

那為什麼求職的美術人員大都只會使用 Adobe 的軟體呢？因為他們在學生時代只學了這套，反正這套又不用錢(盜版)，然後其他軟體又不如這套功能強大對吧？再加上各科老師們的默許(沒錯你們都是幫兇)，才造就了最後這樣的市場環境！我不是針對 Adobe，我只是拿他來舉例而已，不然您還可以再回想一下：
請問您整個學生時代，用什麼軟體寫作業交報告？
每當需要上臺報告時，你用什麼做投影片？
每當有需要修圖時，你使用哪一套軟體？
在需要畫工程圖時，電腦打開的是哪一套軟體？
當您在比較軟體時，是否考慮過軟體的售價？
還有最重要的，每當你的學生使用了你們班上大多數人都使用的軟體以外的軟體時，您是怎麼罵他們的？

而為什麼只有軟體大廠玩得起這樣的市場遊戲呢？因為新崛起的小廠也像這樣放任盜版衝市佔的話，很容易一下子就把資金燒完了！那麼那些大廠要怎麼回補這些早期的開支呢？只好把軟體訂的再貴一點嘍！

於是就這樣，我們在暗自開心貪小便宜的時候，親手把本土的產業掐死在搖籃裡，然後將我們的一切輕易的交付在那唯一的選擇上；直到有一天成為別無選擇的時候，再來抱怨世界的不公和大佬們的貪婪！還記得當年微軟開始要正式進軍中國大陸的時候嗎？面對大陸地區盜版猖獗的情況，人們疑惑微軟要如何賺錢時，比爾蓋茲淡淡的說道： 「中國人喜歡偷，我希望他們偷我們的；等到十年後，我們再來思考如何要他們付錢！」 ^[6]

1. 「成功大學 MP3 事件」, 維基百科, 連結

2. 「避免商業壟斷學生團體反反盜版」, 公視, 連結

3. 「反盜版的深層結構」, 陶在樸, 連結

4. 「反「反盜版」的三大理由」, 葛皇濱, 連結

5. 「軟體財産權：要不要適可而止？」, 王怡, 連結

6. 10年前的盖茨：既然中国人要偷软件，就偷我们的吧, 連結

台語是什麼？可以吃嗎？

Thu, 14 Mar 2019 00:10:00 +0800

相信在臺灣生活的人，一定不會沒聽過「台語」這個詞，但不知是否有人曾經思考過，台語是什麼，為什麼這種奇異的方言要把他叫作台語？

在臺灣有一種奇異的方言普遍被叫作「台語」，而我一直以來對於這個稱呼非常的不以為然！這種語言其實就和中國大陸福建省南方話一模一樣，說實在的，我們小時候聽到大家都稱呼這種語言叫作「閩南語」，不知何年何月開始，才聽到大眾漸漸的改叫它「台語」。

說實在的，本來福建人要怎麼亂叫，與我也沒有太大的關係。偏偏後來不曉得從什麼時候開始，臺灣島內流行起一股，可能是基於種族自尊心還是什麼的，將閩南話和國家認同強勢連結在一起的活動。於是在各種場合就可以聽到閩南話出現，其實這不打緊，畢竟別人愛說什麼方言也是自由；但是去買個東西，對話到一半突然就被切成閩南話頻道是怎樣？用國語與人交談到一半也可以莫名其妙就被切成閩南話頻道還切不回來又是怎樣？以上都是生活交談，本來就不嚴謹，那開會開到一半突然變成閩南語大會，也不會再用國語重講一遍又是怎樣？只有少數稍微體貼一點的人會說「我說台語大家聽得懂嗎？」本來也只是強迫聽閩南語而已，沒想到後來竟變本加厲，還要強迫大家都得說閩南話才行，只要碰上不會說、或者不願意說閩南方言的人，動輒扣上「臺灣人怎麼可以不會說台語」的帽子！

正好搭上那一陣子政府在推行「正名運動」，於是我思考，為什麼閩南話要被稱做台語？若閩南語不是臺語，那真正的臺語應該是什麼語言？

終於有一天，又一位同事問了我「臺灣人為什麼不會說台語？」於是我就趁機問他：「臺語的定義是什麼？」「臺灣人說的話就是臺語」，他說。我就回了：「臺灣族群多元，生活在這個地方的種族至少有十來種，語言數十種，你們是什麼邏輯只把福建人的語言叫作台語？其他省份的人難道是死光了嗎？」他接著說：「他們是後來的外省人，我們是台灣人，本來就住在這裡的！」我說：「喔，原來是本來就住在這裡的人才叫臺灣人啊！可這樣說的話，臺語應該是原住民的語言啊！主流有九大方言，你們怎麼一種都不會啊？」然後他一時語塞，不知該說什麼？我猜他心理知道原因，只是也知道這話絕不能說出口！我猜這時他心理的 OS 是：「原住民不是人，他們是番那！」然後他說：「原住民沒有文字，所以不能算！」「喔，原來如此……不對啊，閩南話也沒有文字啊！」我說。後來怎麼拗的細節我不記得了，反正最後原住民不算就是了！我覺得原住民就算了，反正在臺灣好像也沒有人在乎原住民的樣子。那麼各種位階與閩南人都相似的客家人呢？為什麼客語不是臺語？只有閩南語是台語？「因為客家人太少了，說閩南語的數量最多！」原來如此，使用最數量最大最廣泛的才有資格被叫作臺語，可是這樣也不對啊！「如果在臺灣最多人說的話叫臺語的話，那也應該是我現在說的國語可以叫作臺語啊！怎麼會變成福建話叫台語呢？」最後他真的無話可答，只撂下了一句「反正我說的這個就是台語！」當這種無恥的話都可以說出口的時候，我們沒有辦法再進行任何有意義的對話了，因為再下去就只能剩下全然基於種族立場的攻擊，於是這次的對話就此結束！

我想我這位同事絕對不是特例，類似的對話一定可以重現在很多喜歡講閩南話的人身上， (當然前題是如果他和你願意就這個主題展開對話的話)。於是我大概可以確立一個結論，那就是「台語」和「閩南語」之間全然沒有任何符合邏及而經得起推敲的關聯性，其唯一的連結來自於閩南沙文主義者強攀硬套的結果。

如果您覺得我這番推論過於武斷的話，還有另外一個真實的故事可以支持我的說法：有一個小時候和我住很近的學姊，她是原住民(那個時候叫「山地人」)。在她上小學的時候，有一天，老師發現她竟然不會說「台語」！還對著她說：「你怎麼可以連你的『母語』都不會講！」當她回家和母親提起這件事，她母親非常氣憤的說：「和你的老師說，你是山地人，你的母語怎麼排也排不到閩南話！」後來這位學姊有沒有勇氣和她的老師這樣說我就不清楚了，但這則真實的故事已經明白的說明了閩南主義者的蠻橫無理。

如果你說這只是個個案也沒關係。後來陳水扁當總統的時候推動了這個「鄉土語言課程」，那什麼是鄉土語言呢？在我們這裡，鄉土語言只是寫在文件上的好聽用語，實際上就是閩南語。至於學生來自什麼家庭什麼文化通通不重要，反正通通都來說閩南語就對了！當時我一位學弟，也是原住民，他就拒絕上這門課，「老師要當我就當我，反正我就是不學！」記得當時弄到連家長、校長都跑來處理這件事，最後在家長的同意之下，才「破例」讓這位學生可以不用上閩南語課！

後來我上臺北唸書，開始大量接觸到北部人，剛好認識了一位中學教師。她說：「在我們新竹(還是桃園？太久了，我不太記得)，學生在鄉土語言課是可以依自由的意志選擇不同的語言課程的；若學校太小而沒有足夠的師資，幾間學校會聯合起來開課，然後上鄉土課的時候，學生們就可能會坐校車到別的學校去上課。」看哪！這就是城鄉差距、這就是思想差距！

我對閩南方言沒有什麼感情，對於把閩南話硬稱為台語更是嗤之以鼻！可是社會還要強迫我聽、甚至強迫我應該要會說這種方言、更甚者還能無視我的母語而要強迫我們認同這種方言為「臺灣的語言」！做為一種抗議，我常常喜歡讚美他們：「哎呀，你中國福建話說的好溜啊！」「你們中國人都講方言嗎？」而且「中國」兩個字絕對不能省，就是故意要氣死那些閩南臺獨主義者。也許你覺得我幼稚，但這可能是我在這個大環境下僅剩的表達抗議的手段了！

搬離痞客邦

Tue, 12 Mar 2019 00:20:27 +0800

我打算把個人的部落格搬離痞客邦了！至於個人在痞客邦的部落格應該還會繼續留著，只是不會再花力氣更新維護。我的新部落格在這裡：http://www.huoschen.idv.tw/blog/，而舊的部落格是這個：http://ignatius1895.pixnet.net/blog，歡迎老朋友們舊雨新知，以後可以去新的部落格繼續閱讀支持。

起因

為什麼要搬家呢？那當然就是我長久以來在使用痞客邦的部落格系統上面遇到很多問題，最終導致決定出走！但是在邏列我「個人」在痞客邦遇到的各種困難之前，我還是要感謝痞客邦！感謝痞客邦這個免費的、中文的、在臺灣最多人聚集的部落格，讓我可以從一個門外漢的狀態開啟寫作分享的旅程。我想當時若沒有痞客邦的話，我應該還是會走上寫作分享的路，只是可能要再晚個幾年！

首先是很多人詬病的廣告。這部份我覺得個人還可以接受，畢竟人家給我免費的部落格系統使用，安插一些廣告來賺取收入也是合情合理。但是後來的廣告有點愈來愈誇張的地步，尤其是那個惱人的全版廣告，讓我開始一點點小小的不太滿意！

再來就是對我影響佔比最大的部份，寫作超不方便！老朋友應該都發現我的部落格好幾個月才會推出一篇文章。當然我本身細火慢燉的寫作方式是一個很大的原因，然而還有一個很大的因素嚴重加劇了這個問題。有些朋友可能有發現，我每個時期的文章版型風格都有些變化，那不是我趕時髦為變而變，而是不斷在嘗試在寫作和調整版型之間最佳化的過程。我不習慣在線上平臺直接編寫文章，既不方便也沒有安全感；我也不習慣使用類 Word 那樣的文件編輯器，就是不再習慣了！

我的文章通常都是在自己的電腦上先寫作完成，這些文章通常是用純文本編輯器、按著 Markdown 或 AsciiDoc 格式寫作的。然後要再手工把文件編輯成 HTML 格式，還要搭配使用一些特殊的 CSS 標籤，這樣才不會和痞客邦本身的排版發生奇異的干擾，而這整個過程是冗長又無趣的。我試過一些自動化工具，但轉出來的效果慘不忍睹，最後還是得手工編修。透過自動工具轉出來的文章就只有一篇，無聊到有興趣的人可以自己試著去找找看是哪一篇？總之，這個極不方便、也不人性化、並且最後呈獻的效果也沒有多漂亮的過程，就是最耗時間力氣、也是最容易提升懶惰心的殺手！

痞客邦另一個不完美的地方是版型不佳又不易調整，包含整個網頁的版型以及單篇文章的版面。當然，痞客邦上確實也有一些高手可以把部落格弄的還算美觀，只是對於我這種只略略會寫點 HTML+CSS 的人來說是難以調整的，我不知道要去哪裡寫些什麼 hack code，也花不起錢去買誰的設計來解決我的問題！

而壓垮駱駝的最後一根稻草是，痞客邦不知道在什麼時候更新了系統後，我的部落格首頁的最近文章摘要就只剩下每篇文章一部份的內文，而標題完全消失了！我直到現在還是不清楚這到底是痞客邦的 bug、還是我自己的 CSS 修改和 HTML 文章造成的問題，我試著自己改改設定修正，結果愈修愈亂還改不回來。在這過程當中，累積了數年的不滿開始發酵，我慢慢放棄把它修好的念頭，轉而興起搬家出走重新來過，一次解決所有問題的想法，最後終於促成了實際的行動！

新世界、新天地

痞客邦畢竟是臺灣唯一流行的本地部落格平臺，其他可用的解決方案選擇並不多。曾考慮過 Google 的 Blogger，但 Google 這幾年商業策略上的轉變讓我不是很放心；也曾考慮過 WordPress 的方案，但它的複雜讓我對於資訊安全這一塊沒有把握能夠掌握得當。最後我選擇了自架靜態部落格的方案。

靜態部落格符合我的喜好：簡單、美觀、易於掌握、不容易出亂子！但說實在的，我為了是不是要採用靜態網頁方案糾結了好一陣子，因為靜態網頁難以做到某些功能，其中我最看重的就是留言功能。部落格無法留言，就少了與讀者互動的部份，容易變成報章雜誌那樣單方向的訊息出刊。最後我想通了，反正我的痞客邦部落格本來就沒什麼人在留言，我又何必這麼糾結呢？況且我的有些讀者都會直接打電話、或用「線」程式傳訊息給我，這是讓我能夠放心捨棄留言功能的一個大原因。除非哪天我真的不小心出名了，迫切需要各種互動功能的話，到那時候再來考慮把它加回來吧！

至於目前，若讀者真的有意見要告訴我的話，也不是沒有折衷的管道。知道我是誰的親朋好友們可以直接發訊息給我，其他人也可以在痞客邦的這篇搬家文下面留言給我，雖然痞客邦我不再維護了，但有訊息還是會看的！

回到靜態部落格系統，我採用的網頁產生器是 Hugo，這是一款 2017 年初才開始發展的新生軟體，使用簡單方便又快速，並且版型漂亮，至少可以與痞客邦上面要花錢的版型相比。而 Hugo 上面成千上萬的版型都是自由的！此外，Hugo 方案的自訂功能亦相當豐富，像我的新部落格自己東改西改、增刪導覽列等客製化修改全都非常簡易，幾乎自己翻一翻 README 檔就可以知道如何去完成了！

最重要的是，Hugo 支援許多的輕量標記語言。所以我可以不用再把自己的文章在不同的格式間轉來轉去，還轉不漂亮！我現在甚至可以把一些我平常就有在整理的個人手札筆記等，經過簡單的文句修飾後就能直接丟到自己的網站伺服器去。這裡要套用我自己以前說過的相似話語：「當寫作變得更容易、更沒有阻礙，就可以更經常的發佈新文章，更容易將一時的想法寫下來！」

新舊交接

至於我原來張貼在痞客邦的舊文章未來將如何處理？我的想法是，舊的文章就讓他留在那裡吧！我有空的時候會慢慢把一些比較容易轉移的舊文章轉貼在新的部落格，但有些比較難轉換的可能就算了，或是至少等我更有空的時候再去做。

我搬家離開痞客邦，也就是不再花力氣去維護那個地方，但沒有特別的事情發生的話就不會去對他們做什麼多餘的處理。我發現有部份的技術文章點閱率較高，大概網友喜歡去查特定的資料吧。這些朋友們可以放心，那些資料還會在那個地方，直到痞客邦把他們變不見為止！

就這樣，希望我和讀者們都可以適應新天地！

關於資料備份這件事

Mon, 03 Dec 2018 00:00:00 +0800

關於數位資料的永續議題，我在之前的文章有寫過 ^[1] ，結果文章寫太長，沒什麼人看得下去…… 但即便是這樣，那篇文章對很多問題也只有點到為止，並未深談(沒錯，數位時代的困難和應對太多了)！所以這篇文章，我想要以更淺顯一點的方式，鎖定在資料備份的議題上，給一些實務層面的概念和實行方式。

另外，對於覺得資料備份很重要，但不習慣看長篇文章、也沒有興趣知道細節論述來龍去脈的人，可以直接看最後面的結論，閱讀我建議大眾對備份這件事所建議的簡短總結即可！

1 數位資料備份的重要性

對於在數位時代長大的小孩，我想數位資料的重要性無需多提，畢竟沒有人希望自己畢生的資料有一天就這麼的消失殆盡。一個簡短的故事可以說明一切，想想您是否有遇過或看過別人遭遇類似的事情：一位父親抱著整臺電腦三更半夜到處去求爺爺拜奶奶，「拜託一定要幫我把電腦修好，我女兒從小到大的照片都在裡面啊！」

數位資料其實非常的脆弱，使用傳統紙本保存的資料可以存放數十年到上百年不等；而卻少有保存在同一個數位裝置的資料能夠保存超過十年！ ^[2] 還好，數位資料的完整複製非常容易，因此我們通常會將資料複製數份放在不同地方，並且不斷的複製資料到新的數位裝置上，以此來延續數位資料的保存壽命，這就稱之為資料備份。

然而即便對於擁有資料備份概念的人，往往對於備份的方法不對、或策略不佳，以致仍持續遭受資料損毀消失的風險。因此接下來，我要分享一些我個人對資料備份的相關見解和建議策略。

2 給資料備份新手的一些初級概念

2.1 重複的資料才叫作備份，換個地方存檔不叫備份

多於正常所需要的數量才能叫作「備份」，所以把資料多複製一份放在別的地方才叫備份，只是把原來存在 A 處的檔案改存到 B 處去不叫作備份，這樣資料損失的風險還是沒有降低。原來我覺得這個蠢問題是不需要提醒的，直到我看到「高登工作室」所貼的案例分享 ^[3]

有人拿著一台筆電要來救資料，因為裡面有許多珍貴的照片，但是電腦一開就聽到咔咔咔的聲音，我的判斷是硬碟已經壞掉，除非送硬碟救援，不然資料是不可能救出來的！

而對方卻說：「怎麼會這樣？我這台筆電就是拿來備份資料的說」

看出他的說法有什麼問題了嗎？

沒錯！把資料儲存在一個地方不叫備份，那叫儲存或複製。備份是你在原有的一份資料之外，另外儲存「額外的一份」資料才可以叫備份，所以備份是你的第二份、第三份…第 N 份資料，但一定不會是「僅有的一份」。

— 高登工作室

2.2 不要用外接硬碟備份資料

雖然只要是儲存媒體都可以用來備份資料，但一般來說我極不推薦使用外接硬碟來備份資料。為什麼？一般的想法，備份的東西不就是希望在主要的東西失去以後能夠頂替上來的嗎？那你怎麼能夠拿一個期望壽命比你主要的儲存裝置還低的東西來做為備份裝置使用呢？用白話文來說就是，外接硬碟故障的機會一般比裝在電腦裡面的硬碟來的高，你又怎麼能夠希望在你的主要硬碟故障的時候，一個比主要硬碟更容易損壞的東西可以派上用場？

外接硬碟因為一些設計條件和使用環境的影響，通常較容易損壞，至少比被裝在電腦裡的硬碟還容易損壞，原因如：

外接硬碟通常使用 2.5 吋硬碟，其本來就比常見的 3.5 吋硬碟來得嬌嫩。
外接硬碟因為空間限制，其所能夠設計的防震散熱等條件較嚴苛。
外接硬碟遭受振動、摔落的機會比機箱內的硬碟多得多。
外接硬碟所使用的電源(通常為 USB 埠供電)較不穩定，並且使用中突然斷電的機會(如線鬆脫)也較高。

我曾遇過一個朋友的案例，有一天他把外接硬碟插上筆電時，可能因為接觸不良之類的原因吧，總之系統沒能成功識別檔案系統，於是跳出是否要格式化硬碟的選項，然後這位朋友就直接按下了「確定」，於是他那個用來儲存所有重要檔案的「唯一備份」硬碟就這麼被格式化了！

另外一個親身經歷，我以前有用外接硬碟備份資料的習慣，插上電腦複製完資料並稍事檢查後，就直接把它放進盒子放到櫃子裡靜躺。過了許久後(我想應該有一兩年吧)，當我再次把它拿出來用時，它竟然已經壞掉了！雖然那個硬碟在保固內可以換新，但我從此沒再敢拿外接硬碟來備份資料！

2.3 不要用舊硬碟備份資料

不建議任何狀況下使用舊硬碟來備份資料，理由與前述相同，因為它的期望壽命比需要被它頂替的裝置更低。

有些人每過一陣子就會買新的硬碟，然後把舊硬碟退下來。可是舊的硬碟還能使用啊，那退下來直接丟掉不是可惜了嗎？那就轉去做資料備份使用吧！但在我看來，這個想法是有問題的，應該要把新買的硬碟用做資料備份使用，然後把原來做為資料備份使用的硬碟改做為主要資料硬碟使用才對！

2.4 不要用隨身碟備份資料

雖然隨身碟很方便也很便宜，但不建議使用隨身碟來備份資料，理由與前述相同。畢竟隨身碟是設計來方便使用的，而不是來保存重要資料使用的。撇除製造上的品質問題，就以儲存資料的原理層面來看，隨身碟所使用的快閃記憶體比硬碟磁盤還要不耐使用，甚至放著不用也會讓資料流失！

2.5 不要用固態硬碟備份資料

固態硬碟在近幾年流行起來，價格也在降低。但要注意，固態硬碟最吸引人的地方是「速度」，而不是「耐用性」，在設計上就是如此。固態硬碟使用的是與隨身碟一樣的快閃記憶體技術，即使在一些區塊管理演算法的加持下，其期望壽命依然比傳統硬碟少得多。並且當發生硬碟損壞的情況時，傳統磁盤式的硬碟還可以送資料救援公司花錢救資料；而基於快閃記憶體的儲存媒體則是連救都沒得救，壞了就是壞了！

另外，固態硬碟的容量大小通常比傳統硬碟小得多，拿來備份大量資料不覺得很不划算嗎？而且既然是用在備份的用途上，肯定不會平常需要頻繁存取，傳統硬碟的速度不快這缺點也變得無關緊要了！在這條件下，我是想不出來有什麼理由會想拿固態硬碟來做為資料備份使用？

3 資料備份進階

備份，不就是把儲存媒體插上電腦，然後把電腦上的檔案複製進去，然後退出媒體，收好，就這樣而已嗎？有什麼好進階的呢？事實上關於資料備份的議題還真不少，有些事情若沒注意到，可能會讓你自以為資料很安全而實際上並沒有降低資料損毀遺失的風險，或浪費過多的時間、金錢、精力在沒有實際效用的消耗上。

對於已經擁有備份意識、已經有在實行資料備份行為的人，建議繼續往下看看我對於資料備份的見解，看看是否能夠更進一步改善您資料備份的效用。

3.1 使用不同的儲存媒體

資料備份就是把原有的資料複製一份放到別處去，然而要放去哪？

除非是因為應用軟體的缺陷，不小心把你的檔案給存壞了這種狀況，比如說從前的 MS Office 把檔案開著開著就有可能弄壞檔案 (至於現在這問題是否還存在我就不知道了，我已經好多年沒用 MS Office) ，否則在原地複製一份的作用並不大，因為一旦硬體裝置發生故障，就是上面的所有檔案一次全沒了！十幾年前，還有人會把檔案備份到同一個硬碟的不同磁碟分割下(也就是 C 槽 D 槽等)，畢竟那時候的作業系統比較脆弱，有機會會把檔案系統給弄壞。可是現在作業系統普遍比較強健，很少再發生無故把檔案系統損毀的案例了；反而是不同的磁碟分區都還是在同一顆硬碟上，當發生硬體損毀時，上面資料一樣全毀！因此請謹記，備份的資料一定要放到另一個實體儲存裝置上，這樣才能夠第一步的真正分攤風險。

然而，同一臺電腦上的不同儲存媒體也仍然承受著相當大的資料損壞風險！例如因雷擊而導致的硬碟損壞就會同時摧毀你電腦裡的所有硬碟，例如駭客入侵、或者前一陣子很流行的勒索病毒也會一次對電腦上所有的儲存媒體下毒手，就算都沒有這些意外，備份硬碟與主要硬碟在開機時一起過電、一起運作，它們理論上的故障時間其實也沒有相差太多！

因此，備份所使用的硬碟或其它儲存裝置應該要另外存放，除了備份或還原時以外，平常不與系統接在一起。像我從前就會去裝硬碟抽取盒，然後要備份資料的時候才把備份硬碟插入電腦主機，然後開機進行資料備份工作。

理論上，做到這裡所描述的使用不同儲存媒體來備份資料，就已經足夠安全了；接下來要面對的主要反而是人心、習慣、與惰性所帶來的問題！也就是說，接下來要講述的方案幾乎都是在花錢解決人的各種習性所造成的問題，若您自認非常勤勞並且一絲不苟的話，就可以不用再理會下面所論述的內容。

3.2 備份工作的阻礙及備份週期增加的原因

我就先用簡單的問句來破題吧！那些平常有在做備份、或是自認有在備份的人，請問你上一次備份你的檔案是在多久以前的事？

截至目前為止所說明的備份方案在實務操作上存在巨大的問題，就是執行資料備份的週期會不自覺的被拉的很長，導致當資料損毀遺失情況發生時，從今日至上一次執行備份工作之間的所有資料都無法回復。

我們來分析看看造成資料備份週期被拉長的原因有何？

硬體設備裝卸費時費力：
執行備份工作之前必須要把備份硬碟從某處挖出來裝上電腦，你絕對不會想要常常去做這件事。何況不是每個人都像我有裝硬碟抽取盒，所以拆裝硬碟通常還需要拆卸電腦主機外殼等工作，這直接造成只有在時間過了很久以致你內心不安的時候才會想做這件事！
工作中斷：
我想大部份人的電腦並不支援硬碟熱插拔，所以當你動念想要備份資料時，需要將電腦關機再開機。除了開關機的時間消耗外，這還導致你無法在正在處理某些工作時、或玩電動、或看電影的時候進行資料備份工作。這提高了你打消執行資料備份工作念頭的機會，也就拉長了資料備份的週期。
資料整理：
我想現代人需要備份的資料可能不再是幾張磁碟片的大小，而是動輒上百 GB、數量上萬的資料，這麼大量的資料光進行複製工作通常就足以消耗數小時甚至一整天，所以你一定不願意常常執行備份的工作，至少不願意在週末突然想到的時候來做這件事！另外對於這麼龐大的資料，通常人不會甘願無腦式的直接複製，而還會想要整理一下，比如說把之前亂放在電腦各處的檔案集中到 D 槽去、刪除一些不需要的檔案和過時的檔案等等，這些額外的工作提高了執行備份時的體力和時間消耗，使你不會願意輕易執行備份工作，也就又拉高了備份週期。

那要如何解決這些問題呢？就是要盡可能的降低每次執行備份工作的成本，做到讓你動念時就可以隨時執行備份工作的程度，這樣你就可以三天兩頭備份資料，甚至讓電腦隨時都在進行資料備份，達到縮減備份資料與現行資料的版本落差。

從前我就是採用硬碟抽取盒機制來備份資料，導致備份週期長達數個月，去年硬碟壽終正寢時，我的備份資料竟然是半年前的！在痛失半年間的資料後，我狠下心來花了一萬多塊錢買了 NAS。

3.3 減少備份工作的阻礙

這裡提出一些建議，來解決執行備份工作前所會遭遇的阻礙：

3.3.1 設置伺服器

在家裡放一臺備份資料專用的檔案伺服器，這臺機器就長時間處在開機待機狀態，隨時準備接收備份資料，所以當需要備份時便無需再拆裝什麼東西或甚至不需要走過去把機器開機。機器雖然一直開著，但應該長時處在休眠待機狀態，只有在備份工作開始時才被喚醒，工作完成後很快又去睡了，所以平時的電力消耗微乎其微，沒工作的時候甚至也不會對硬碟通電，硬碟壽命得以保障。雖然安置一臺伺服器對一般人來說並不輕鬆，但這樣的工作做一次即可，之後每次執行備份工作時，便可在工作不中斷的情況下直接將檔案上傳給備份伺服器。而由於所走的通常是家裡的區域網路，網路傳輸速度是比網際網路快得多幾個數量級的。

3.3.2 使用增量備份機制

增量備份就是每次備份時只複製自上次備份以來被新增、移除、過更動過的檔案，這樣可以略過大量不動的檔案，減少每次備份所需要的時間；不過這種增量備份請一定要使用軟體來做，比方說 tar 或 rsync，千萬不要手工做這些事，否則不只沒有減輕負擔，還增加了遺漏的風險！

3.3.3 使用檔案同步機制

除了增量備份外還有一種比較炫的同步備份機制，就是讓兩邊保持一樣的檔案結構，在執行備份工作時只需比對兩邊的檔案樹有什麼不同，然後複製缺少的或修改過的、刪除多餘的即可。同樣的，請使用軟體如 rsync 等來做這個工作，而不要手工來做！

同步備份比起增量備份的好處是兩邊的資料結構是一樣的，當你隨時需要檔案時可以隨時進入伺服器抓取特定檔案；而在提取增量備份內的檔案時，通常需先將檔案從壓縮中解開。

而比起增量備份的缺點就是同步備份比較難保留版本變更記錄，比方說在增量備份機制中進行還原時，可以指定要還原到某一次執行備份時的狀態；而同步備份下通常只能拿到最新的檔案，使得在面對如資料誤刪或遭受資料入侵綁架等狀況時較難以招架！

3.3.4 自動執行備份工作

經過伺服器架設與增量或同步備份的選定後，除了第一次進行備份工作時以外，每一次進行備份工作的時間縮短了。備份所需要的時間依兩次備份間的資料差異而不同，而因為備份頻率的縮短，兩次備份間的資料差異通常不會很大，此又會更進一步的縮短每次備份所需要的時間。以我個人的情況而言，每次備份所消耗的時間約在數十秒至幾個分鐘之間，這個成本已經低到我可以在電腦用到一半的時候，隨時想要就可以執行一下備份的地步。

因為備份的成本降低，執行檔案整理後再進行備份的心理壓力會降低，使得這個阻礙不再存在！你可以隨時整理檔案，然後執行備份，可以整理一點點就備份一點點，沒弄到的下次再整理再備份，而無需給自己心理壓力必須在本次的備份前完成什麼程度的資料工作。

更進一步，你還可以設置自動執行備份工作，使得連先想到備份然後再點一下執行備份的步驟都免了！你可以設定自動在每週的什麼時候，或每日的什麼時候讓電腦自動執行備份的工作，甚至有一些比較酷的軟體還可以在背景工作，當偵測到某些被監視的資料夾發生檔案異動的時候就自動執行備份工作！

另外，不要問我 Windows 要怎麼設定，我也不會，我都直接改 crontab。

3.4 從 RAID 談起，相同的備份條件以三為限

說到備份，有一個古老的(但仍然好用)技術就會被提起，叫作鏡像磁碟陣列(RAID 1)。磁碟鏡像的原理很簡單，就是透過硬體或軟體把兩顆以上的硬碟組成一個群組，把它們當作只有一顆硬碟來使用，所有對硬碟的讀、寫操作都會同時對群組中的所有硬碟執行同樣的操作。這樣，所有的硬碟裡都會擁有相同的資料，當發生硬碟損壞時，只要不是全部的硬碟一起損壞，我們都可以簡單的把壞的硬碟拔掉，把其它硬碟的資料直接對拷到新硬碟後裝上即可。這樣只要群組中的硬碟有一個是好的，就可以忍受在其他硬碟損壞的狀況下繼續正常工作，而理論上群組中的硬碟同時損壞的機率非常低，尤其當硬碟數量愈多的時候機率愈低！那這樣，我們用 100 個硬碟來組一個群組不就萬無一失了？

這裡就要提醒一個迷思，任何的備份方案都是有失效條件針對性的。以磁碟鏡像為例，它所針對的失效條件即為硬碟自然老化所造成的故障，在這個情況下，使用 100 顆硬碟而他們全部同時老化死亡的機率當然是非常低，但若發生了不是它所針對的失效條件呢？比如說被雷擊？我看哪怕是 10000 顆硬碟都會 100% 全部報銷！前幾年日本海嘯所引發的核電廠事故不就是個活生生的例子！

若您有足夠的資金多加一顆硬碟來組成磁碟陣列的話，甚好，可以減少機件故障帶來的資料喪失風險；若您能夠投資三個硬碟來組成鏡像陣列的話，更好，基本上已經可以忽略自然老化所帶來的資料喪失風險；但若您要投資四個以上的硬碟來組成鏡像陣列，事實上是不會有什麼壞事情，只不過有點浪費了！如果您能夠有多餘的閒錢一次購買這麼多多餘的硬碟，何不把錢拿去再買一臺伺服器電腦呢？至少這樣可以減少單一一臺電腦的電源異常或系統異常導致同臺電腦硬碟全部損壞的機會！以此類推，若你有錢在自己家裡放下超過三臺的伺服器，何不把一些伺服器改放到別的地方呢？這樣至少有一天你家失火的時候，這些伺服器不會一次全燒光！

結論就是，每一個資料備份相關的手段都有特殊失效條件的針對性，對於針對同一個失效條件的同一種手段的冗餘數量，建議以三為限。不要問我三這個數字怎麼來的，這只是一個經驗值，你喜歡的話改成四或五也可以。而且這個數字不是絕對必須遵守的，冗餘太多了真的不會有壞事，只是包含資金在內的各種資源開銷比較大而沒有效率而已！

3.5 購買 NAS 代替自行組裝架設伺服器

使用獨立運作的伺服器來代替每次拆裝儲存媒體的工作確實是減輕不少平常的負擔，然而一般人對於「伺服器」這三個字是多麼的陌生，甚至連聽說過伺服器這個詞的都少之又少，遑論要求大家要有能力能夠自行在家裡架設備份用的檔案伺服器？如果能夠像買電腦一樣直接購買現成的伺服器回家插電使用的話不是最好不過了嗎？在從前伺服器是很貴的，但近年許多平價的伺服器被推出，拉起了家用伺服器的市場，讓在家裡安裝伺服器這件事變得不再那麼不容易，其中專門被用來用做檔案備份和分享用途的小型伺服器就叫作 NAS。

購買現成的 NAS 回家可以省去大部份非數位領域專業的一般使用者研究、安裝、配置、和管理一臺伺服器所需要消耗的大量心力，雖然目前還做不到隨插即用的地步，但一般人按照產品說明書的步驟完成伺服器的設置和用戶電腦端的設定已不再是太困難的事情。

即便對於像作者我這樣的半專業用戶而言，購買 NAS 代替自行組裝的伺服器也是極具吸引力的！相比於自己拿零件來組伺服器，專門的 NAS 機器小巧易安放於家中角落。而且 NAS 的最大耗電功率通常約在 20 瓦上下，相比一般 x86/64 架構的電腦動輒上百瓦的電力消耗是節省不少，若再加上 NAS 大部份的硬體設計讓其可以在閒置時自動關閉硬碟並休眠這點，則其平常的電力消耗更是低到可以忽略。當然，上面所提及的優點也可以使用一些準系統等微型系統來做到，我個人當時也有思考過這個方案，然而這些微型系統通常都使用 2.5 吋的硬碟，然而 2.5 吋硬碟和 3.5 吋硬碟在耐用性和選擇性上相差是很大的！除了專用 NAS 機器外，我在市面上找不到使用筆電規格機板又可以內接 3.5 吋硬碟的設備，於是最後我還是購買了一臺 NAS 做為我家的檔案伺服器使用。

3.6 NAS 的選購方針

市面上的 NAS 琳琅滿目，該如何選呢？簡單來說我的建議是：買能夠塞進兩顆硬碟的最精簡最便宜產品即可！

要買兩槽以上的機器是因為這樣才能裝兩顆以上的硬碟來做鏡像磁碟陣列，而五槽六槽以上的就太多了，如果你有閒錢買這種的，還不如去購買更多臺的 NAS 機器！

然後面對市面上眼花撩亂的各種 NAS 功能，我們又需要怎麼樣的呢？既然買 NAS 是為了做檔案備份用途使用，那我們就只需要可以設定自動備份檔案的機器即可；至於多出來的各種什麼家庭檔案共享、家庭多媒體中心、媒體串流輸出……等等通通不需要，也最好把這些功能在設定中直接關閉！為什麼？還是基於風險管理原則。機器上運作的功能愈多，就愈增加硬碟的讀寫消耗、也增加更多因程式軟體弱點而造成的風險，尤其即時串流的解碼很吃硬體效能，這種硬體又會提高耗電。特別是若你把 NAS 設定成可以經由網際網路存取(也就是你人在外面仍然可以連線到家裡的 NAS 來存取檔案)，則又會增加被入侵的風險，尤其服務開愈多風險愈大！那我們再回過頭來審視買 NAS 是為了什麼？不就是為了分散保存檔案、減少檔案損失風險嗎？那搞這麼多提高風險的東西又是為了什麼？如果你的家裡真的需要多媒體分享中心，當然可以，不過推薦另外買一臺機器來使用，而不是把這個需求和資料備份的機器弄在一起！

對於單純的檔案備份工作而言，市面上最低階的產品大概都足以勝任，所以我建議 NAS 只要購買最低階(但要兩槽以上)最便宜的即可！

3.7 購買 NAS 或其它專用機器值得嗎？

很多人即使知道一臺專用的檔案備份伺服器是很方便的，但面對它的價錢卻又買不下手！確實，以我後來買的 NAS 為例，機器就花了我五千多塊錢，再加上兩顆硬碟後，總共花費一萬二上下。要說這個錢值不值得花？讓我們思考一下這個狀況：有一天你的硬碟終於壽終正寢，而這顆壞掉的硬碟裡面存放了你所累積的保貴資料，幾經掙扎後，你把硬碟送去給專門的硬碟資料救援公司去搶救，資料救援的費用應該在數萬塊上下，實際會依據救出來的資料大小增減費用。那麼若你這時願意花費數萬元來救回你心愛的資料的話，何不在一開始花費只有好幾分之一的錢來做長久的資料備份方案呢？

當然不設置相關的機器設備也可以做到備份與保存資料，如同我前面所述，若您擁有紀律和毅力來強迫控制自己手動備份檔案的週期的話，使用硬碟抽取盒的方案即足矣！

3.8 購買線上空間代替家用 NAS

購買 NAS 的方案即便已經省下了大量自己架設伺服器所需要的知識和技術開銷，仍然無法做到開箱即用。例如網路相關設定，NAS 即便把整臺機器都整合好了，也沒辦法預先知道你家的網路環境長什麼樣子、沒辦法預先知道要對它連線的電腦該如何設置？所以這些最終還是需要由用戶來進行設定。因此對於大量的非專業電腦用戶來說，NAS 或其他專用伺服器仍然是個具有門檻的方案，好在也是最近十年興起的線上資料儲存和資料同步服務補足了這方面的需要！

所謂的線上儲存，其實就是讓別人去處理伺服器的建立與管理相關工作，然後你直接使用他建立好的伺服器就可以了！當然對方可能會向你收取一些管理費用，並且依據收費的多寡來開放你所能使用的空間容量等資源，也就是說我們可以無需花費心力在伺服器相關的工作上，直接購買別人所提供的服務、租用已經建置完成的伺服器空間即可！提供這樣服務的公司也不是少數，比較有名氣的如 Dropbox 和 Google Drive 等皆是。線上資料儲存服務的最大優點就是使用和配置非常容易！通常只要能夠連線到相關服務的網頁、下載安裝同步軟體、輸入身份認証資料後，背景程式就會開始默默的同步特定資料匣下的所有檔案。這種方案不需要使用者了解 TCP/IP 連線和網路位址、不需在家裡拉線和設置網路分享器、也不需要處理到底需要幾個磁碟鏡像和資料備援回復功能，還可以在外地隨時同步檔案而無需擔憂入侵風險等，其方案的使用難易度與一般聊天通訊軟體相似，足以讓廣泛的一般使用者輕鬆使用。

另一方面，線上服務的缺點其實也不少，首先它的費用不算低。雖然線上服務通常都有免費方案，但免費方案的容量通常不敷現代人的使用！以 Dropbox 為例，截至 2018 年 11 月為止，其購買方案中的 1 TB 儲存空間需要花費一年 99 元美金來租用，大約就是一年 3000 元新臺幣左右；但同個時間的 4 TB 硬碟大約 3800 元新臺幣，若使用兩顆硬碟設為鏡像陣列的話，平均 1 TB 約需花費 1900 元購買，若假設一顆硬碟可以使用三年的話，平均 1 TB 使用一年的成本約為 650 元，就算再算上 NAS 機器的成本攤提(假設 5500 元攤兩年)和一些電費支出， 1TB 空間使用一年的成本也才 1400 元左右，整整是線上方案的一半！上面的算式比較保守一些，都是拿保固期當設備壽命來計算，若實際的設備壽命更長的話，則成本將更低，甚至可以再砍半！

線上服務提供的容量有限，一樣以 Dropbox 為例，一個帳戶最多也只能購買到 2 TB 的儲存空間，對於有些檔案比較龐大的用戶來說可能會不夠使用；其他的線上服務供應商也許提供的容量更大，但總有人不敷使用，比如說常拍照片的攝影師或常拍影片的 youtuber！

線上服務的資料傳輸速度會慢很多。因為資料都是透過網際網路與服務供應商的伺服器連線，其速度先天就不如自己家裡的區域網路，即便是你家中的兩臺電腦要同步資料，這資料也需要在網際網路上繞一圈，若再加上您家裡所申裝的網路速度不夠快、或者對方網速壅塞等因素又會更進一步降低實際的網路傳輸速度。因此若您經常需要同步大型檔案的話，請記得最好去購買大型網路公司所提供的相關服務，或乾脆直接在自己家裡放個伺服器吧！

線上服務還有資料的保安問題，畢竟你的資料全都放在別人公司的機房裡，那麼您信不信賴他？他會不會什麼時候倒閉不玩？或者是偷看偷利用或流出你的檔案？這些就足以影響您使用其服務的意願。就像不少公司因為一些疑慮而不考慮購買 Google Mail 服務，仍然選擇自己架設 mail server 一樣，有些要求資料保密性的公司、國家和政府單位、或者一些疑神疑鬼如史諾登的個人，依然會選擇自己架設檔案備份相關系統。而對於一般的個人用戶而言我想這不是個問題，畢竟各種線上免費信箱和免費網路空間都用的這麼開心了！你要和我說你很在意資料保安所以不願意使用線上儲存同步服務？

因此，雖然我很重視數位資料的保存問題、逢人就推廣資料備份的重要、我自己也購買設置了 NAS 機器，但我推薦給絕大多數朋友的第一優先備份方案卻是購買線上儲存服務，然後設定與自己的各電腦同步，即完工！雖然線上服務的金額比較高，但若把架設維護家用伺服器所需要的金錢、知識、技術、以及各種折騰給算上的話，那麼線上服務其實還是相當廉價的！

4 結論

不論您是看完了前面的論述看來這裡，還是直接從開頭跳來這裡，總之我要最後簡單的重點提要式整理我建議你實行的資料備份方案，依照推薦順序描述如下：

建議直接購買線上儲存空間和資料同步服務來備份您的資料，比較知名的有如 Dropbox 或 Google Drive 等。
若線上服務不能符合您的需求，比如說因為成本、空間大小、傳輸速率、或資料保安等問題，那麼請購買 NAS 或其他類似的專用伺服器來做為資料備份使用。
若您的需求非常特殊以致一般 NAS 不能滿足，或純粹就是想要體驗自己架站的感覺，那麼請自己從硬體到軟體到網路環境組裝配置屬於您自己的伺服器(群組？)
若您從來沒有意識過檔案備份的重要，或者從來沒有實際實行過任何的備份方案，那麼請立刻開始備份您的數位資料，不論使用外接硬碟還是隨身碟什麼的都好！我知道我一開始就叫大家不要使用這些東西來備份資料，但對於沒有備份習慣的人，真正且立刻開始執行備份的工作才是最重要的，畢竟有總比沒有好！

1. 「數位時代需要面對的困難：資訊保存與接駁」, 解·惑生, 連結

2. 「網際網路之父：我都用紙張保存資料」, 鏡週刊, 連結

3. 「請不要再用行動硬碟「備份」檔案了」, 高登工作室, 連結

比較幾個網路檔案系統：SMB、NFS、和 SSHFS

Fri, 15 Jun 2018 00:00:00 +0800

因為最近的需要，在折騰網路檔案分享相關的東西，於是上網搜尋了不少資料。要讓多位使用者可以互相分享、交換檔案，就需要佈置網路檔案系統，而網路檔案系統種類繁多，因此很自然的會產生一個問題：「我應該選擇哪一個檔案系統？」

看到網路上對這個問題的討論，絕大部分都集中在檔案傳輸效能上，讓我覺得頗為奇妙！因為不同的檔案系統存在不同的結構差異，在什麼場景下應該最適合什麼檔案系統這個問題並不是一個效能屬性就能夠覆蓋的，在不適合的環境下選擇不適合的檔案系統，甚至會讓你付出數倍的心力來處理這個檔案系統所引發的各種缺陷！因此接下來我就要分享一些這陣子折騰網路檔案系統的心得，希望能夠幫助有需要的人在選擇網路檔案系統時能夠更全面的思考。

網路檔案系統就是能夠讓網路上某臺電腦的某個設為分享的資料匣，把它模擬成使用者自己的電腦上的磁碟的機制。這樣，使用者就可以用一般的方法讀寫這個看起來像自己電腦裡面的磁碟，但實際上確是在存取遠端電腦上的檔案。網路檔案系統種類非常多，這裡只會簡單介紹並分析三個比較知名、也是我這回嘗試過的網路檔案系統： SMB、NFS、以及 SSHFS。

SMB/CIFS

SMB 是 Server Message Block 的縮寫，其又被稱為 Common Internet File System (CIFS)，其實就是「網路上的芳鄰」一樣的東西，讓數臺區域網路內的電腦能夠彼此分享交換檔案。 SMB 最初由 IBM 發展，後來微軟在 SMB 的基礎之上發展了 CIFS，然後不久 IBM 就放生了 SMB，於是後來(2006 年) 微軟發展的新版 CIFS 乾脆就把 SMB 這個名字拿過來用，叫作 SMB 2.0。這中間亂七八糟沒人搞得清楚的故事太多 ^[1] ^[2] ，總之現在普遍都以 SMB 稱呼。

SMB 其實沒什麼優點，它最大的優點就是 Windows 內建 SMB 功能 (網路上的芳鄰或 Windows 分享資料匣)，所以在一般的個人電腦上配置 SMB 通常還蠻容易的。其它的作業系統對於 SMB 的支援也算容易，UNIX 家族一般安裝配置 Samba 軟體即可存取 Windows 的共享資料匣，甚至建立 SMB 伺服器供其它電腦存取。

SMB 的缺點其實不少， SMB 是建基於 NetBIOS 的通訊協定，因此只能在區域網路內同網段的環境下使用，即使後來推出了 NetBIOS over TCP/IP 的技術，也少見有人使用 SMB 建置網際網路上的檔案分享。不同於一般配置 SMB 的容易，如果你要配置一個可以與外界交流的 SMB 檔案系統，那可就夠你折騰了！

SMB 的另外一個缺點是安全性低，這主要歸咎於兩個因素：其一是因為美國出口法規的關係，使得 Windows 使用了安全性不足的加密機制；其二為 SMB 協議本身的缺陷加上 Windows 上面相關實做中存在不少數十年修不好的臭蟲，從而導致 SMB 機制變成病毒和駭客入侵的管道，例如前一陣子惡名昭彰的 wannacry 勒索病毒便是利用 SMB 的漏洞入侵用戶電腦。

在效能的表現上，SMB 屬於中庸，沒有什麼特殊之處。綜合以上因素，使得 SMB 常被使用於以 Windows PC 為主的區域網路內，例如公司內部的檔案分享伺服器。

NFS

NFS 是 Network File System 的縮寫，是另一種網路檔案分享交換機制，最初由 Sun 所開發，現今廣泛流行於 UNIX 家族。

NFS 有兩大優點，第一是在 UNIX 家族中設置與掛載都非常方便容易，第二是速度快、效能佳。如果做個類比，那麼 Windows 之於 SMB 就如同 UNIX 之於 NFS，只要在 export 檔案填寫要分享的資料匣和允許連線的電腦(可能需要安裝相關套件)，然後別臺電腦就可以直接 mount 連上了！

說到效率，NFS 可是幾個主流的網路檔案系統裡面最快速的，這得利於幾個因素。第一是它在設計結構上就非常講究效能，例如它不進行複雜的登入認証機制，僅使用客戶端的連線位址做為識別用戶的手段；它捨棄了較慢的使用者名稱比對與轉換工作，直接使用兩端的 UID 與 GID 做為檔案權限依據；它基本上沒有對傳輸資料進行加密(NFSv4 以後加入了可選的加密機制)而省去了加密的開銷等等。第二是它在大部份系統上的實做也做了非常多的最佳化，甚至被編為系統核心模組，將主要的工作放到核心層去執行。綜合以上因素，使得 NFS 成為最快速高效的網路檔案系統。

然而 NFS 也存在不少缺點，最明顯的就是安全性低。未使用加密連線使得傳輸資料被窺探的可能性提高，另外 NFS 僅依賴網路位置來辨認用戶的方法，使得任何人都有機會假冒特定使用者進行連線，只要該使用者能夠變更自己的連線 IP 以取代之即可。

另一項可能會令人惱火的問題是在於檔案的所有權上面， NFS 直接取用檔案的 UID 與 GID，並且在兩端不做任何轉換，真的把兩臺電腦當成一臺了！這造成了一個問題，一個 UID 或 GID 在兩端不一定是同一個 user、甚至不一定存在該 user。以用戶端來說，它有機會讓你看到奇怪的檔案擁有者；以伺服端來說，它讓用戶可以冒充任何伺服器使用者的權限存取檔案 (對於伺服端的問題，可以透過一些分享設定來緩解)。

還有一個問題可能會造成網路配置與管理上的不便。 NFS 本身雖然架構在 TCP/IP 上，但卻依賴 RPC (Remote Procedure Call)服務，於是 NFS 伺服器需要監聽多個網路埠口，並且其中多數還不是固定埠口而是變動埠口。這個現象會讓對外網路的防火牆等相關設定維護工作較為棘手，也容易因為開放過多埠口而增加入侵風險，這個問題與傳統的 FTP 服務一樣。

最後一個問題是在客戶端配置的難易性上。 NFS 在 UNIX 家族環境下極易配置使用，但桌面市場上佔有率極高的 Windows 並不屬於 UNIX 家族。雖然 Windows 本身有支援 NFS 的功能，但相關服務預設為關閉，且要啟動並使用該功能所需要的工作需要執行一些麻煩瑣碎的設定，導致要讓 Windows 終端連上 NFS 主機變成一件麻煩事。

SSHFS

SSH 是被廣泛使用在伺服器用途的超好用工具，它除了提供遠端登入並操作遠端電腦這個最初被賦與的任務外，還衍生出了許多功能，例如檔案上下載、加密連線穿隧、以及由 SSH 實現的 FTP 功能(SFTP)，此外還有一缸子的軟體透過 SSH 來運作，比如說執行遠端檔案同步的 rsync 程式等。簡單來說，SSH 在 UNIX 體系所涉入的工作可謂包羅萬象，若說什麼事情都需要 SSH 也不為過。而 SSH File System (SSHFS)便是其中一個利用 SSH 功能的軟體，它可以透過 SSH 存取遠端電腦的資料匣，再透過 fuse 系統在用戶端模擬為一個本地磁碟，即成為一個實現檔案分享交換的網路檔案系統。

SSHFS 有非常多的優點，大多體現在安全、管理、與配置上面。安全就不用說了，SSH 本身就是非常優秀的加密通訊系統，透過 SSH 執行網路資料傳輸基本上就保障了通訊的資料保密性。

在網路連線的管理上，SSHFS 依賴於 SSH 服務，因此比照 SSH 辦理即可。 SSH 只使用單一一個 TCP 埠口，沒有變動埠口的麻煩和風險、也沒有非 TCP 通訊模式在網際網路不易溝通連線的問題，對防火牆以及網管人員來說應是非常方便的一個方案。

在配置上，因為 SSHFS 的連線與檔案交換其實是依循 SSH 下的 SFTP 協議，因此伺服器管理的部份完全比照 SFTP 辦理即可，對伺服器來說，SSHFS 用戶和 SFTP 用戶並無任何不同。如果你已經會架設與管理 SFTP 的話，那麼你並不需要額外學習什麼東西。在用戶端，UNIX 家族只要安裝 SSHFS 套件後就可以掛載伺服器上的資料匣了，難易度一般； Windows 用戶也可以在安裝 WinSshFS 和 Dokan 軟體後，簡單的設定就能連線掛載 SFTP 上的目錄，甚至比連線網路上的芳鄰還要簡單。

說到它的缺點，大概是認証設定稍嫌複雜、以及還不夠廣泛流行。因為連線時需要認証身份的關係，所以需要額外配置一些與認証有關的設定，在 Windows 上其實很簡單，WinSshFS 會處理完一切，只要在設定的時候填入連線帳號密碼或金鑰檔即可；但在 UNIX 家族上就比較複雜，要不就是客戶端需要產生並設定金鑰，然後還要交給伺服器管理員來匯入，要不就是使用 sshpass 套件來使用密碼登入，並且還要另外配置密碼認証腳本。這使得在 UNIX 家族上設定 SSHFS 不若其它網路檔案系統便利，這是安全的代價。

SSHFS 知名度較低，比較不容易在目前的網路分享交換環境上看到它，然而這其實不是 SSHFS 本身的缺陷造成！SSHFS 不夠流行的主要原因是因為發展的比較晚，我不清楚 SSHFS 的應用在什麼時候開始的，但 Windows 上的 WinSshFS 大約是從 2012 年以後才開始發展，因此在多數的公司行號等內部所需要的網路分享機制上，就直接選擇了 SMB 系統至今，有些是因為歷史因素、有些是因為 IT 人員不知道 SSHFS 的存在和能耐，最終造成目前 SSHFS 不廣泛被使用的狀態。

最後還有一項劣勢在於效能的表現上。其實 SSH 的各方面表現都算優秀，單以效能來說應算得上水準不錯，畢竟在其他眾多使用 SSH 的資料傳輸場合上(比如說 rsync 或其他資料穿隧)都是快速順暢的；只是因為前有 NFS，使得在與效能有關的評比分析上往往落於下風。不管再怎麼努力，多了加密解密的工作是不可能比沒有加密的流程還要快的！若再加上連線認証、使用者名稱轉換等機制、核心層與使用者層的優勢、以及其他細項的話，那麼 SSHFS 在效能上拼不過 NFS 是非常自然的，而這也是安全和便利的代價！

綜合比較分析

綜和所有的分析後，我基本推薦在幾乎所有的場合下，網路檔案系統的首選應是 SSHFS。 SSHFS 的不論安全性、網路管理難易度、都是非常有利的，在效能表現上也算傑出，對於終端電腦的配置算是簡便，尤其是在以 Windows 為主的用戶環境上。特別是在用戶需要跨越網際網路與檔案系統連線時，它的各種優勢表現將最為明顯！

對於 SMB 則是不建議使用，會需要使用到這個檔案系統的時機除了伺服器不想花多一點心思在配置分享上以外，大概只有在應用環境絕大部分為 Windows 系統、並且嚴格要求不能在用戶端電腦安裝任何軟體的情況下吧！另外強烈建議 SMB 應該只規劃在阻隔良好的內部網路中使用，並不是說 SMB 沒辦法在經過一些調整後能夠由網際網路連線進來，而是這麼做除了增加許多管理上的困擾外，還會讓內部的安全風險飆升。以前一陣子的 wannacry 來說，資安專家建議關閉 TCP 埠口 445、甚至是停用整個 SMB 機制，此時如果你的公司是靠著 SMB 來分享檔案的話，那做為 IT 人員應該會不知所措吧！

另外在某些狀況下選用 NFS 會是個不錯的選擇，例如當你需要非常快速的檔案傳輸，比方說經常讀寫大檔案的時候。不過注意 NFS 只適合在可信任的區域網路，以及各上網終端固定且已知、沒有動態 IP 跳來跳去的環境下才能放心使用；若網路環境複雜而堅持使用 NFS 的話，可能會未蒙其利先受其害！

還有一個狀況就是嵌入式裝置的開發用途中，嵌入式裝置的各種運算資源稀缺，在 PC 上面沒什麼感覺的加密等工作到了嵌入式裝置上可能會顯得吃力、各種加密程式庫在以 MB 計算的儲存裝置中顯得體態擁種。而若你只是因為一時新奇而想在小裝置上使用 SSH 進行腦海中的一些酷炫工作的話，那麼首先你必須要把 OpenSSH 重編譯並移植到裝置上、當然還包括了它所依賴的一眾工具，我想這絕對夠你先折騰個三天三夜的！這時候 NFS 小巧且通常內建在許多核心程式碼內的優勢就凸顯出來，幾乎是只要讓裝置能連上網路後的下一步就可以透過 NFS 和你的開發 PC 連線交換資料。在開發嵌入式裝置的場合，通常都是在辦公室內可受信任的小型區域網路內進行，安全性什麼的不是很重要；而嵌入式裝置上通常也只有一個使用者帳號就是 root，比較不會有什麼不同 UID 搞得眼花撩亂的問題，而簡單純粹的 NFS 在這情況下將能替你省去不少麻煩！

以上就是我對幾個主流網路檔案系統的評價和測試心得。

1. Why You Should Never Again Utter The Word CIFS, 連結

2. CIFS vs SMB: What’s the Difference?, 連結

談自由軟體

Mon, 23 Apr 2018 00:00:00 +0800

「自由軟體真是好東西！」我就直接開門見山不賣關子了，這篇文章就是來說服大家使用自由軟體的！

你常使用盜版軟體嗎？沒有盜版軟體就不知如何使用電腦嗎？望著許多軟體高貴的價格讓你買不下手，不知學什麼好嗎？自己的數位檔案必須依賴特定軟體、甚至特定版本才能正常開啟使用，害怕有一天這軟體不再能用時，一輩子的檔案就付諸東流嗎？想研究、學習、了解軟體到底是如何工作的，甚至喜歡寫軟體嗎？或者只是不知道什麼是自由軟體而想要了解嗎？如果你符合以上任一情況，你就是這篇文章的寫作對象，我也誠摯的邀請你來了解，最好實際使用自由軟體，也許它會給你一些解答。

從我第一次認識什麼是自由軟體，就漸漸愛用這種東西。它有些優點、有些缺點、有些與以往的認識不同的特性，對我來說可是瑕不掩瑜、物超所值。這幾年來常常向人介紹推薦自由軟體，發現大多數的人甚至沒聽說過自由軟體，知道的人裡也對它有著不少錯誤認知，甚至有些人因為一些誤會而不敢去使用自由軟體，平白失去了與這麼好的東西的機緣，甚為可惜！於是就想寫一篇文章來向大眾介紹我所認識的自由軟體。以下文章將分幾大部份進行，文章結構將儘量以要點模式，如同問答項目般的編排，以利讀者快速跳至感興趣的主題閱讀、或是未來回頭檢索。

1 什麼是自由軟體？

在解釋什麼是自由軟體的時候，我通常喜歡拿部落格做為例子。我們應該都看過書、也買過書，一本書的生成需要作者的智慧、出版的資源、以及銷售通路的支援，因此讓想要閱讀書本內容的人花上一些錢來購買是非常合理的。但不知道各位對網路上一大堆的部落格有什麼看法？部落格的文章數量不只多，還涵蓋各種不同領域，有些甚至是非常專業的內容，就這麼放在網路上無償的給我們觀看，不知各位有沒有想過這些作者勞心勞力圖的是什麼？我想有些人沒想那麼多，就是喜歡分享自己的知識、經驗；有些人可能受到利益單位的業配贊助而寫作；有些人可能根本就是公司僱員，因此寫部落格文章是它的工作；還有些人可能圖個名聲和知名度；當然也有更多我沒想出來的原因…… 那麼，把文章換成程式碼，把部落格換做是網站平臺，又何嘗不是如此呢？

由部落格文章的模式可裡理解，有一些人寫了軟體，把程式碼分享給全世界，讓有需要的人可以自由使用。自由軟體最重要的精神就是「自由」、「開放」、和「分享」原則，所有的人不只可以自由使用軟體，還可以藉由閱讀程式碼來研究軟體的運作，甚至修改軟體來符合自己的需要，最後再回饋自己的修改，分享給其他的人，這就是自由軟體的概念。軟體界的著名人物 Richard Stallman 在 1980 年代左右發起了「自由軟體運動」後，自由軟體有了比較明確的定義。不管實際的授權條款在細節上有什麼不同，所有的自由軟體一定提供了以下 4 個保障，否則就不能自稱為自由軟體 ^[1] ：

The freedom to use the software for any prupose.
你可以基於任何用途使用自由軟體，軟體發行人不能限制你使用軟體的目的。因此很明顯的，任何自由軟體不會有什麼個人版、家庭版、專業版、還是企業版什麼的，自由軟體只會有一個版本，而所有的使用者都可以使用全部的功能。
The freedom to change the software to suit your needs.
你可以自由的修改軟體來符合自己的需要。為了能夠自由修改軟體，自由研究軟體的權利當然是必要的；為了能夠自由的研究軟體，軟體發行商提供原始程式碼(包含所有相關文件)也成為責任。自由軟體要求，所有的「軟體客戶」都要能夠容易的取得軟體程式碼，並且不需要加價購買或設下其它障礙，因為提供程式碼是軟體發行商的義務！
The freedom to share the software with your friends and neighbors.
你可以自由的分享自由軟體給任何人，自由軟體不能夠為這件事情設下任何阻攔。所以下載自由軟體後把它分享給眾親朋好友是合法的，即使你並不是軟體原作者。
The freedom to share the changes you make.
這點與上一點是一樣的，如果你對軟體做了修改，你也可以把這些修改分享給別人。唯要注意的是，依據實際授權條款的不同，在某些條款下你對軟體做出的修改是必須要分享給你的客戶！

使用某一套自由軟體在更多的權利義務細節上還要看實際的授權條款規範如何而定，然而這些授權條款差異所影響的都是開發人員或軟體開發商這些需要「修改或衍生程式碼」的人，而對於通常僅「使用」軟體的一般大眾其實沒有什麼影響，所以就不再細究。對於有興趣想要了解的人可以自行參閱相關文章 ^[2] ^[3] 。

做為對比，人們通常會用「商業軟體」或「專有軟體」這些名詞來指稱那些自由軟體或開源軟體以外的其它類型軟體。

簡單來說，自由軟體給了使用者極大的自由，這也是自由軟體號稱「自由」的根本原因。不可否認自由軟體中絕大部分的所謂自由是為了軟體開發人員而設，然而對於通常不參與軟體開發的一般大眾，自由軟體也連帶的賦與了很多在一般商業軟體上不尋常的，在使用和分享上的自由。

1.1 都是什麼人在開發自由軟體？

其實問這個問題就和問「都是什麼人會去寫部落格」是差不多的！不同於部落格文章通常都是一位作者寫成，自由軟體的作者通常是一大群，我們稱之為「社群」。也許一些自由軟體的開發是由某位人士發起的、或者由某位人士原作、或者開發中由某位人士所主導，但基於開源共享的精神，往往會有一大群人分享出自己的修改，可能是某些問題的修正、可能是某種新功能的加入、可能是讓程式可以在某個平臺上執行的修改、也有可能是某個既有功能的更有效率寫法等等，大家你來我往，最後就是每個人都貢獻了軟體或大或小的一部份。因此，我們便常用「社群開發」或「社群維護」這樣的詞來說明自由軟體的開發團隊。

這個開發團隊不同於我們所認識的公司或機關行號的嚴明組織，自由軟體社群由散居在世界各定的軟體開發者組成，靠著電子郵件互相來往，大多數人素未謀面。人員來去自由，個人比較有空的時候可能多負擔一些開發工作，而忙碌的時候可能就從當中抽身。這種組織其實看起來比較像是朋友圈，我們稱這種組織叫鬆散組織。

至於開發人員也是千百種，有些人是基於喜歡分享知識、有些人喜歡與各路好漢一起工作的感覺、有些人圖個名利或磨練的機會，還有些人是受雇於公司行號組織機關的僱員，參與某自由軟體的開發是他的工作。雖然英雄好漢來自四面八方，但通常那種自願參與自由軟體開發的人都是佼佼者，畢竟擁有這等能力和興趣的人才會想要在工作生活之暇來做開發軟體以利眾生的事情！

1.2 自由軟體都有哪些？

問自由軟體都有什麼軟體，就和問網路上可以免費閱覽的部落格文章都有些什麼是一樣的！任何使用自由授權條款發行的軟體都是自由軟體，改天你自己寫了一個軟體並以開源共享原則發行，則世界上的自由軟體就又多了一套。因此我不可能列舉出世界上所有的自由軟體們！不過當中有一些比較流行或知名的自由軟體，比如說 Firefox、FileZilla、PCMan、LibreOffice 等等，可能你或你的朋友之間已經有人在使用了也說不定喔！另外，這裡還有教育部為各種用途，特別是教育用途所推薦的自由軟體列表 ^[4] 可做為參考。

2 常見的誤解和疑問

2.1 我又不會寫程式，自由軟體的所謂「好處」對我有意義嗎？

自由軟體有很多好處，比如說可以研究程式碼、可以修改程式碼等等，可是我又不是程式設計師，這些好處為我是不是和沒有是一樣的？我又不會寫程式，怎麼可能去「修改程式以符合自己的需要」？

我想這是很多的軟體一般使用者會有的疑問。的確，一般的使用者因為不會寫程式也不會改程式，所以好像沒有辦法直接受惠於自由軟體的開放自由；而自由軟體對一般人的直接好處好像也只剩下使用和分享上的自由了！這裡我提出的見解是，改程式這件事其實不需要大家都會，只要有人去做這件事，基於共享原則，大家就能受惠！

想想，你對於一套軟體的期望，難道沒有別人和你懷有同樣的期望嗎？對於一套軟體上的問題或錯誤，難道沒有別人遇到嗎？對於軟體上尚不足的地方，難道沒有人也覺得不足嗎？對於一個流行的自由軟體，其中的開發者自然也多，其實很多的問題可能一段時間後就會得到解決；而很多期望的新功能，也許已經有一票人正在開發中也說不定！就算你用的這套軟體比較冷門，拿著程式碼在手也不至完全無法做事，因為你不會寫程式的話，可以請會的人幫忙啊！只要付出足夠的誘因，總是可以找到人解決你的問題；但對於拿不到程式碼的專有軟體，除了期望並等待廠商可以優先想到你的需求以外，還能有什麼做為？

2.2 自由軟體和免費軟體是一樣的嗎？

這是一個很普遍的問題了，即便是使用英文做為母語的人也常會問出這個問題！自由軟體「通常」可以讓你無償取得使用，而免費軟體也是如此，那麼它們之間的不同是什麼？

免費軟體其實仍是商業軟體，一切遵守商業軟體的規則和策略，只是基於某些商業考量，「目前」軟體的發行商讓你免費使用他的軟體而已！有幾個地方可以體現出這個不同，首先你只擁有軟體的「使用權」，拿不到軟體程式碼，沒有研究、修改、發佈的權利。第二是保障性，就如前所述，免費軟體就是商業軟體，目前基於商業策略考量給你免費使用，但未來的任何時候，原來的發行公司都可以片面改變發行策略。也就是，即使只是無償的使用權，也沒有人能夠保證你能永遠擁有！

而自由軟體給你完善的保障，即便原開發商打算改用商業授權重新發行軟體，對於原來在自由授權下已發行的軟體仍是沿用原來的授權(由授權條款的條文內容所保障)。在真實的案例中，一群忿忿不平的自由軟體開發者甚至會拿開源條款的程式碼直接分支出另一個自由的專案繼續開發維護下去，比如說 DivX 和 Xvid 之間就是這樣的關係 ^[5] ！

免費軟體其實只是商業軟體當前願意讓大眾無償使用的狀態，類似的狀況還可以在所謂「試用軟體」上找到，不過它又做出了更多在使用上的限制；而自由軟體是完全不同的概念，它強調了使用者的自由，也就是無拘無束的自由，比較類似於人身和思想上的自由。誤解的來源大概是來自於自由軟體(Free Software)字義上的多意問題吧！在英文裡，人身自由、思想自由可用 free 形容，比如說「I am a free man」；然而用來形容免費、無償的形容詞也是 free，比如說「The beer is free for you」。因此現代開始有些人喜歡使用更加精準的 Libre 一詞來描述這個身體思想上的自由概念。

2.3 聽說自由軟體安全性差？

認為自由軟體(或開源軟體)安全性差的觀念通常是以訛傳訛造成 ^[6] ！

認為自由軟體有安全性問題的立論點通常是「因為程式碼大家都看得到，所以哪裡有弱點也容易找到！」這個說法事實上說的很合理，對於看不到程式碼的軟體需要使用很多瞎猜的方式來找尋可能可以利用的弱點；而開源軟體因為有程式碼可以看，程式在哪裡做了什麼事清清楚楚，從程式碼找弱點是相對方便快速得多！

但是實際上的使用經驗卻剛好相反！自由軟體的安全性表現通常遠好於封閉原始碼的商業軟體，這又是為什麼呢？人熟能無過？只要是人寫出來具有一定複雜度的軟體就會有蟲。然而自由軟體大家都看得到程式碼，在無數隻眼睛觀看之下，程式的問題往往很容易被挑出並處理掉；有心人士要想在程式碼裡面偷加一些奇怪的後門，而能夠躲過大家的眼睛，也非常不容易！反而是封閉原始碼的私有軟體，軟體的品質和安全性全仰賴開發商的努力，問題是一間公司能夠有多少開發人員？在產品策略和用人調度之下，又有多少人能夠付出心力在持續的關注和維護安全性問題？自由軟體的開發維護人力來自於社會大眾，想想身邊親朋好友，就算 100 人裡面才有一個軟體工程師，就算 100 個軟體工程師裡面才有一個高手，就算 100 個高手裡才有一個可以在閒暇之餘參與自由軟體開發維護，這樣算來全世界會有多少個自由軟體開發人員？又有哪間公司可以請得起這麼多人來開發維護一個產品？並且這些人還都是高手中的高手！

最終在實際上，對於流行流通的自由軟體，軟體問題通常很快的被發現，也很快的被修補完畢，使得實際表現上，自由軟體相比於同類的商業軟體品質更好也更安全。

2.4 聽說使用自由軟體沒有支援也沒有保障？

有些人認為使用自由軟體沒有保障，因而裹足不前，一直不願意嘗試自由軟體，這當中又以中小企業用戶為最。

使用自由軟體沒有保障的說法來自於，自由軟體通常是由一大群鬆散的人員開發而成，當真的遇到什麼事情的時候，找不到人可以負責！企業軟體選用系統常要求一定的長期穩定性，而也因為沒有一個可以「負責」的人或機構，許多中小企業便為此感到不安，怕自由軟體的開發有一天說不玩就不玩，或者想變就變、想新就新！

我的回應是，先說說個人用戶，對於大家可能常使用的商業軟體比如說 Windows 或 Office 等，微軟有給你什麼保障了嗎？你在遇到問題的時候有打電話給微軟讓他負責過嗎？最後還不是自己 Google 或問親朋好友來解決！

不管是個人用戶還是企業用戶，對自由軟體的任何問題其實都可以在網路上發問，熱心的網友通常會解答你的問題，甚至多數的問題可能早有解答。當然，沒有任何人有義務對你的問題提出解答，或是在你期望的時間內提出解答。若你希望可以有個人真正為你負責，讓你放心的把心中的不安交給他處理的話，其實可以花錢購買商業支援。只要你願意付錢，很多相關公司會樂於提供你對於特定自由軟體的保障，比如說維護服務讓你可以安心的使用這套軟體，而不需去管現在 OpenOffice.org 的所有權到底是 Oracle 還是 Apache；客製化服務可以讓你對軟體的許願成真，而不需去期望社群的人一定要在多少時間內做出這個全世界可能只有你在用的功能；諮詢服務可以讓你在對軟體有各種疑問或操作問題時，一通電話打過去就能有人為你解答。提供這類服務的公司很多，比較有名的就有 Red Hat 提供 RHEL 服務、Canonical 提供 Ubuntu Linux 服務、以及臺灣的晟鑫科技提供 OxOffice 服務和企業導入服務等。

最終，要改變的只有我們腦袋裡的觀念而已。傳統上，軟體的各種服務都是由開發商提供，畢竟對於原始碼不開放的軟體，除了原廠大概也沒有別人可以提供什麼有效的服務；而自由軟體的服務單位往往不是原開發單位，甚至有時候對於同樣一套軟體可以找到兩家以上的服務提供商。對於閉源軟體，軟體的服務往往是附加性質，實際的內容取決於開發商的資源配置考量，甚至保障性不足。比方說你若有一些舊軟體必須在 Windows 98 上執行，那麼你現在還能夠買到 Windows 98 的服務支援嗎？相對的，即便對於一套已經過時許久的自由軟體，只要你能夠支付足夠的資金，就可以找到能夠接手的人！而專門的服務商通常在軟體服務上會更全面週到，畢竟提供軟體服務就是這些公司的主要工作和收入來源！

最後補充強調一點，經過以上說明後，可能有些人會誤解以為：若不購買服務支援，那所使用的軟體就沒有保障了！事實上購買服務支援不是必要的，不管是為個人用戶還是企業用戶而言。想想你使用別的軟體、甚至是下載破解的軟體，你會因為覺得用起來沒有保障而不用嗎？當你遇到問題時，可以找親朋好友、或上網搜尋解決辦法，再不濟，程式碼就在那裡，也可以自己跳下去處理！購買商業服務其實多半是企業用戶花錢省事、或者是想要把工作和責任分出去給別人的手段之一，你總不能要求經營一家小餐廳的商家還要養一票工程師，就為了處理餐廳裡面使用到的某些軟體日常可能發生的問題吧？但反過來說，也是有不少具有一定軟體維護能力的大公司，他們會選擇依靠自己的 IT 部門人員來處理公司內的各種軟體相關問題，而不會向外購買軟體服務支援。

2.5 聽說只要用了自由軟體就一定要把所有程式碼全公開在網路上！

有些人因為認為只要使用了自由軟體，就必須要把所有的程式碼放網路上公開，甚至因而不敢去使用自由軟體！這也是一個非常神奇而令人感到訝異的問題！

自由軟體的很多原則和規範通常只有在進行軟體開發有關工作時才會有所影響，也就是說，對於甚至可能不會寫程式的一般使用者，去擔心這個問題就是完全多餘的！你難道有遇過因為下載了 Firefox 後幫同學安裝，可是沒有隨附程式碼給他，然後竟然因此吃官司的事情嗎？

可是若你是想要對軟體從程式碼上做一些修改或研發的話，你就會需要去了解你所使用的軟體授權具體賦與你的權利義務是什麼？即便如此，你也未必一定就要公開程式碼給大眾。首先是有些授權准許你不公開修改或衍生的作品，這就是很多商業公司喜愛的軟體授權方案，讓他們可以使用現成程式的功能，卻不需要公開自己的程式碼。再者是任何的自由軟體其實並沒有要求你必須將程式碼公開給「大眾」，而只要求你要將程式碼附給你的「客戶」。也就是說，如果這個人不是你軟體的用戶，你就沒有義務送他程式碼；若你只是改改程式碼自己用而沒有散佈給別人，因為這時軟體的客戶就只有你一人而已，也就沒有需要將程式碼公開出去。

我曾在一家公司裡目睹一個真實的案例，有一位軟體部門主管遲遲不肯導入版本控制系統。一問原因才知道，該主管認為使用開源的版本控制如 SVN、Git 等會讓自己的專案程式碼必須公開在網路上，而商用的版本控制系統又需要不少錢，以致遲遲無法決定！顯然這位軟體研發主管完全沒有搞清楚自由軟體授權、要不然就是把 Git 系統和 GitHub 服務給搞混了！事實上以這個案例來看，完全無需擔心自由軟體的授權問題。因為在這個條件下其實是他們只是「使用」Git 來管理自己的檔案(我故意不講程式碼，免得有些人搞混)，他們又沒有要去「修改」Git 程式，即便修改了，也只需要公開修改後的 Git 而不是其管理的所有專案程式碼！就算如此，也只要他們那個部門的人可以拿到修改後的 Git 程式碼就好，完全無需公開在網路上！遇到這種因為神奇的理解錯誤而錯失使用自由軟體機會的案例，我通常感到既可惜又無言…… ^[7]

2.6 自由軟體沒有版權？

有些人以為自由軟體是沒有版權的軟體，這是個誤解。雖然這個誤解似乎對於純粹使用軟體的人沒有什麼影響，但會使可能有志參與自由軟體開發的人產生猶豫！

雖然自由軟體本者共享的基礎鼓勵分享，甚至有時會用 Copyleft 一詞做為形容(與 Copyright 相對)，但是自由軟體並不是沒有著作權的公眾領域軟體！你可以分享、可以修改、可以衍生創作程式碼，但不能拿了別人的程式碼後說你才是原作者！自由軟體可以讓人隨意散佈，但原創作者仍享有完整的著作權，包含商標權，而這也是為什麼很多自由軟體改作品都會改名字的原因，比如說 OpenOffice.org 和 LibreOffice、以及 DivX 和 Xvid 的關係就是這樣。

甚至，在作者群單純明確可控的狀況下，產品所有權人還可以改變軟體發行的授權，比如說取消自由授權而改以商業授權發行(如 DivX)、或使用多重授權來發行(如 wolfSSL)。

簡而言之，自由軟體提供了使用者分享、研究、修改、與改作的自由，但並沒有要求作者必須要拋棄著作權！

2.7 自由軟體如何產生商業收益？

有些人會好奇，自由軟體要如何融入商業活動、產生收入？有這樣的好奇或疑慮是非常合理的，因為若一種軟體模式與商業環境互相矛盾衝突的話，會使得公司行號不願意投入此種類型軟體的開發，使得這種軟體終究只能活躍於一群完全做公德的小圈子。而脫離商業社會的資源和付出，也將使得軟體的發展動能受到極大限制！

自由軟體主張自由但其實並不反商，事實上完全允許商業行為；只不過因為自由軟體獨特的特性與一般商業軟體不同，使得無法以一般常見的商業行為來套用在自由軟體身上牟利！

2.7.1 販賣

首先，自由軟體完全是可以被販賣的，自由軟體運動 ^[8] 的發起人 Richard Stallman 年輕時就賣了不少自己寫的軟體！雖然目前大部份的自由軟體都可以在網路上無償下載，但自由軟體的規範並未要求軟體一定要無償提供給大眾。自由軟體規範軟體發行人有義務在分發軟體時，將程式碼一同送交予被發送的對象，也就是所謂的「客戶」。因此不是任何人都能夠向您索要程式碼，他必須要先成為你的產品客戶，而這個過程沒有任何商業限制；換句話說，你完全可以像一般商業軟體一樣販賣自由軟體，然後再把程式碼附送給買軟體的人 (比如說 Red Hat Enterprise Linux 就是這樣的例子)；當然，若你選擇把軟體放在網路上供自由下載(比如說大部份常見的自由軟體)，則任何人都可以輕易成為你產品的用戶，那程式碼就必須要能夠隨意下載了！這個時候，軟體執行檔反而不是必須提供的，因為有了原始程式碼，任何人都可以自己把軟體二進位檔給編出來！

當然，再更深入了解就會發現，這種使用一般商業軟體的思維來販賣自由軟體的路是走不下去的！任何客戶都可以在拿到你的程式碼之後轉兜售或直接公開在網路上，因為自由軟體完全不阻止散佈軟體的權利！不過通常因為商標權的關係，這種被拿去轉發行的軟體通常都會改個名字和商標，比如說 OpenOffice.org 與 LibreOffice 之間的關係，或 Red Hat Exterprise Linux 與 CentOS 的關係就是這樣。也因為這樣，大部份的軟體一旦以自由軟體授權散佈，就乾脆直接放給大眾下載，省得麻煩，結果就只剩下少部份的自由軟體需要花錢購買。

這也是為什麼當很多問起自由軟體與免費軟體有什麼不一樣時，自由軟體擁護者往往都會說：「自由軟體不是免費軟體，免費只是它的副作用」。的確，自由軟體真正在乎的事情是使用的自由和分享的精神，只是湊巧大部分的自由軟體因為某些因素而決定免費發送而已！

2.7.2 服務

那麼一般如何從自由軟體的販售中得利呢？經過前面的解釋會明白，自由軟體本身很難賣錢，而一般靠著自由軟體營利的公司主要販售的是其提供的軟體服務！需要比較實際的解釋嗎？自由軟體通常很容易取得，然而很多的問題在後面才慢慢浮現：
打算改用自由軟體，但與你之前使用的軟體差異很大，不知如何學習入門嗎？沒關係，我來教你，人數很多的話還可以安排教育訓練課程(比如說公司導入 XX 軟體系統時)。
一時找不到需要的功能應該如何操作嗎？軟體使用上遇到不明白的問題嗎？一通電話打來，我為您解答！
使用軟體覺得不安心，因沒有人可以為你負責嗎？社群那票人求新求變，程式一直在更新，怕有一天與現在的環境不相容又無法處理嗎？沒關係，交給我來維護你的系統，我們比社群穩定、也願意為您負責！
您有特殊的需求需要特別的客製化，卻無能力進行修改，或不想倘這混水嗎？沒關係，我們為你處理，還有保固喔！
您還有更多不同的個人需求嗎？沒關係，通通都可以提出來，只要您願意繳錢，我們儘量配合您的需要！

雖然一般個體用戶很少願意去使用這樣的服務項目並付出金錢，然而對於大部分的企業用戶來說，這樣的服務確實有他的價值和需求，而提供服務的公司就能從中賺取收入。

2.7.3 市場策略

另外還有一種商業模式，促使商業公司投入自由軟體發展，甚至投入大量僱員進行開發！這種方式通常不會產生直接的收入，它所產生的利益主要以產業發展利於該企業的面向出現在商業戰場上。比如說 Red Hat 顧忌於 KDE 的獨大，使得其本身無法抵抗 Troll Tech 公司的任何開價，這促使 Red Hat 大力支持另一套新興而尚不健全的類似工具 GNOME 的開發 ^[9] 。 GNOME 的發展成熟使 Red Hat 在購買 Troll Tech 的 Qt 產品授權時得到談判的有利條件，隨著 GNOME 的發展健壯並吸引眾多商業大頭倒戈支持，最後甚至迫使 Troll Tech 將 Qt 以自由軟體授權開放！還有更多其它的例子都可以看到，在某些適當的狀況下，商業公司會投入資源開發完善特定的自由軟體，以獲取商場上的可觀利益。比如說眾多硬體廠商會加入 Linux kernel 的開發，好使 Linux 在自己的平臺上得以正常運作，甚至連 Linux 的死對頭 Microsoft 都不得不貢獻 Linux kernel 程式碼 ^[10] ^[11] 。

2.7.4 捐款

除了直接或間接的商業收入來源促使商業團體投入開發外，也有更多自由軟體的開發維護純屬公益性質，這些軟體大部份靠著願意付出額外時間和熱情投入自由軟體的志士來開發與維護，或透過一些公益基金會來維持運作。其中有些單位會接受外界的捐款以作為支持，例如 Mozilla 和 LibreOffice。

3 自由軟體的缺點和侷限

不能否認的，每種不同的東西都會擁有不同的特性，其中有些是優點而有些會成為缺點，自由軟體當然不例外！在澄清了一些關於自由軟體的誤解、和介紹自由軟體的好處後，接下來就要說明一些我觀察到的自由軟體的侷限、或不足的地方，這是為了讓人能從更全面的觀點來了解自由軟體。

在自由軟體以外的軟體種類中，佔比最大、特性差異最大、也是最常被拿來與自由軟體對比的軟體種類大概就是一般常見的商業軟體了！因此我在下面的部份也不免俗的使用商業軟體來與自由軟體做一些比較和評論。

3.1 品質

前面提過，自由軟體雖然大部份由熱情的自願者貢獻勞力，使得自由軟體「通常」的情況下比其它軟體更為高品質、強壯、安全、高效。因為能夠有閒為公眾提供熱情的通常都是高手中的高手，再來是全世界的自由軟體開發人員數量之多，不是任何一間商業公司可以比較的，又加上自由開發者沒有商業公司的關於資源和策略所產生的強制性的開發重點移轉聚焦，讓每個開發者可以針對他所在意的問題做出最完美的解答。

然而事情並不總是如此，除了商業公司當然也能夠聘到高素質的開發人員並產生出高品質的產品這個原因以外，自由軟體的品質往往與開發人員的數量形成密切關係！但是前面不是才說過自由軟體的開發人員多到沒有一間公司能請得起嗎？全世界的開發人員是很多，但實際上每一套軟體得到的關注程度不同。某套軟體的志願開發者通常都是該軟體的使用戶，因為功能不滿足、或發現問題等機會後因緣際會跳出來貢獻才能，這導致使用者數量龐大的流行軟體如 Linux kernel、Firefox 等通常擁有海量開發人員；但無名、冷門、或特別專業領域的軟體開發者往往就寥寥可數，軟體的品質自然不易提升，在這種情況下，商業公司的同類型產品更容易擁有完整強大而高品質的表現。當然這不是絕對的！也是有極度流行流通而使用者眾的軟體比如說 OpenSSL，但裡面卻是亂成一團；或是像 Git 這種幾乎是一個人開發成型的軟體，卻沒有人能夠挑剔它的品質或功能。少部份的例外總是存在，但以大體來看，自由軟體的品質幾乎與使用者數量和流行流通狀態呈現絕對的關係！

3.2 高手思維

自由軟體的志願參與者通常擁有很高的素質，然而在某些面向上這反而成了缺點！怎麼說呢？高素質的開發人員能夠提供軟體無可挑剔的品質，但在使用體驗這個方面，高手與一般非專業使用者的想法往往大相逕庭。比方說，對於一般電腦使用者，你會願意使用 Office 軟體製作文件還是使用 LaTeX？你會願意嘗試有圖有按鈕有動畫的 FileZilla Client 還是純文字命令介面的 ftpget？壓縮解壓縮檔案的時候你會想用 WinRAR 還是 tar + xz + gpg？諸如此類，會讓你覺得為什麼這些狂人使用的東西都讓你覺得這麼難用這麼反人類；然而反過來其實他們也覺得你愛用的軟體難用又彆扭！說到底其實就是使用軟體的思考立足點不同所造成。

由於大部份的讀者應該都不是電腦專業用戶，我就用別的東西來做為解說。大部份的人應該都有照相的經驗，看過專業攝像師拿著超專業的相機可以拍出極美的照片，但若讓一般普通人拿上這個相機，那拍出的畫面應該普遍醜過使用傻瓜相機拍攝的照片，搞不好連如何操作才能夠成功拍下一張照片都是一件不容易的事情！如果說看在普通人眼裡，專業照像機是難學難用難掌握的話，那對於軟體又何嘗不是如此？若讓一位專業攝像師拿著傻瓜相機來工作，可以想像他抓狂的模樣！因為相機自動決定的攝像參數如此笨拙，卻又沒有可以人為介入的方法，就連想要搭配一些如閃光燈、快門延長線等等自己的週邊器材都無從做起！而這不也是那些電腦高手不喜歡使用所謂方便好用的大眾軟體的主要原因之所在嗎？在大部份沒有商業公司介入的自由軟體裡，絕大部分的開發者既軟體使用者會把軟體設計的非常完美；不過這個完美是站在高手立場來看的，於是對於普通人來說，很容易就會產生難用、難學的深刻印象。看看早期的 Linux 和各種 shells 的發展、再看看早期 Git 的操作方式，就不難發現這個脈絡。

依實際的使用觀察可發現，雖不是絕對，但自由軟體中一般使用者使用體驗良好的軟體背後通常都有商業公司的影響力存在。這很容易理解，就如同前面說的一樣，試想若汽車的市場和開發一直都只由一群技術高竿的車手和技師來主導的話，那麼像自動排檔、娛樂媒體等發明大概不可能會出現在現代汽車上面了！由一群軟體開發高手研發的軟體，往往只能在專業用戶這個小圈裡面流行，而難進入大眾市場。一個能夠被一般大眾所接受的軟體，除程式內容外，美術、人因、地區化、與行銷推廣等資源缺一不可，最終造成通常只有商業勢力介入的產品才能夠普及於大眾的結果！

3.3 過度強制開源

其實這個點有一點一竿子打翻一船人的味道，並不是所有的自由軟體都具有這個「缺點」，不過偏偏常見的一些基本軟體經常會以類 GPL 的授權發行，以致這項特點所產生的影響力往往足夠強大。

自由軟體提供了使用者特別在程式碼上的極大自由，但有時候這點會讓商業發行有所顧忌。依據每個軟體的使用授權不同，有些授權如 GPL 會要求對於軟體的修改、改作、延伸創作等之後的作品也要以相同授權釋出，甚至僅僅只是自己的軟體使用到這些軟體的功能，也會受此條件束縛！舉個例子，這樣的條件下在 Linux 底下就算寫個 hello world 程式也會需要以 GPL 授權釋出，因為你的程式會需要呼叫 printf 函式，這功能在 Linux 上通常是由 glibc 程式庫提供，而該程式庫的授權(在從前)即為 GPL！這會讓很多程式碼內含商業機密的產品公司不願意為某些環境開發產品，例如說顯示卡驅動程式或其它敏感儀器的驅動程式，這也是為什麼從前 Linux 一直缺乏驅動程式的重要原因之一。

過度強調自由到「強制」自由開放的情況，反而使得很多開發商對這個生態卻步，最終反而不利這個生態的活性。也因此種局面，才催生出後來對開發者較為寬鬆的 LGPL 等授權，至此才緩解了這種蕭條的情況！

3.4 專門應用或冷門應用的缺乏

雖然我們推崇使用自由軟體，然而並不是在任何的用途上，都有自由軟體可以使用！大部份的自由軟體由一群懷抱熱情的志願人士發起並參與，那麼這些人大多散佈在什麼領域，大概就決定了自由軟體注定只活躍在這些應用上。對於任何一個應用需求之下的軟體，首先必須要存在有具有該需求的足夠數量使用者，才能撐起這個市場；這些使用者裡面，也許有一些具有程式開發專長；而具有程式開發專長的使用者裡面，也許有一些會想要貢獻才能來開發自由的軟體；又需要具備一定的數量的具有程式開發專長且願意做出貢獻的使用者，才能撐起這種自由軟體的品質和完整性。因此我們可以得到一個簡單的結果：在擁有數量足夠龐大的使用者或潛在使用者的應用用途上，才比較有可能出現可堪使用的自由軟體！

看看實際的狀況，在一些實際需求強勁的應用，比如說文書處理、網頁瀏覽器、作業系統、或編譯器等，我們可以找到各種不同的自由軟體，其中大部份的效能、功能強度、和安全性等表現甚至超過同類型的商業軟體；再看到一些比較專門的應用領域，比如說影像處理、音訊處理、CAD/CAM 等，雖然也存在一些自由軟體，但各種的功能表現比起同類型商業軟體可能就比較遜色；若再往下看看一些更專業或更冷們的應用，比如說 CFD 等，則連要找到一套存在的自由軟體都非常困難！這個道理非常明白，在使用者群足夠小的領域裡，基本上能夠具有專業知識到可以涉入這個領域而成為軟體使用者，人數就夠少了，更遑論還要期望其中有軟體開發能力並且具有熱情的人來開發自由軟體！當然，反過來說，在需求普遍的應用用途裡，你一定可以找到傑出的自由軟體；特別是在電腦科學和軟體工程相關領域，這是自由軟體數量最多、種類最豐、綜合表現最為強悍的勢力範圍，因為在這個應用領域的使用者群中，具備軟體開發能力的比例相較其它領域是非常的高！

那麼除了志願開發者外，商業力量是否會介入冷門領域來開發自由軟體呢？我想答案是否定的，不然這個問題就不存在了！商業公司不會無端涉入自由軟體的開發，因為這不符合獲取最大商業利益的原則，商業上的力量往往是在一些特別的市場競爭態勢下，才導致投入自由軟體的開發相較之下能夠得利，甚至迫於情勢才會進入自由軟體的開發工作。在專業又冷門的用途上，加入競爭所需要的知識、技術、和經驗等門檻很高，使得通常是少數公司寡佔市場，而在這種狀況下，販售閉源的私有軟體顯然更能夠賺得利潤並掌握使用者們！

綜和全部的因素，最終造成在需求群體過小的應用領域裡，通常只有少數的商業產品可以選擇！而在普遍流行的需求、特別是與電腦科學或軟體工程有關的用途中，若你沒有選擇使用自由軟體將會非常可惜，因為錯失了使用地球上最強大軟體來解決你的問題的機會！

4 為什麼你應該要使用自由軟體？

如同我最開始說的，我極力推薦大家使用自由軟體。在知道了自由軟體是什麼、以及了解了一些有關它的各種特性和長短以後，接下來說明我鼓勵大家使用自由軟體、或者說為什麼你應該要使用自由軟體的理由。

4.1 免費

除了極少見的自由軟體需要花錢買之外，絕大部分網路上能找到的自由軟體都可以被任何人免費下載使用的！這大概是所有自由軟體擁護者都會向你吹捧的好處，但很不幸的這一項特點也是一直以來最有爭議的一項！

絕大部份的自由軟體不用錢，可以讓人無償取得並無限制的使用，這點沒有爭議；但是不需要授權費不代表使用該軟體的成本就一定比較低！我想絕大多數的一般使用者並不是從一開始接觸電腦以來就在使用自由軟體，不然可能也就不需要來看有關什麼是自由軟體的文章了！在這樣的前提之下，從你已經上手習慣的軟體轉而使用自由軟體，會不會一下子不習慣、不順手？會不會有一些常用的功能找不到在哪裡？會不會甚至有些使用上的思維也需要轉換？更別說還有從前使用舊軟體所累積下來的成果要轉換到新的使用環境可以接軌的程度，又會耗費不少力氣！這就是數位時代所謂的「轉換與遷移成本」，我在我的前一篇文章有探討過這一部份 ^[12] 。若把這部份的成本也算上去的話，那麼「轉而使用」自由軟體所需要付出的代價不見得會小於繼續使用已經使用了數年的既有軟體。

對於個人用戶而言，轉換的成本並非高到無法跨越，通常只要下定決心，遇到的困難其實都不難解決；然而對於企業用戶而言，轉而使用自由軟體所需付出的成本就更為高昂了！企業用戶面對的是一群的員工要脫離已經上手的軟體轉而使用另一套軟體，其中每一個人的資質、接受度、固有經驗和習慣等都不一致，轉換所需的相關教育課程和訓練少不了；若再加上企業在先前已經基於舊軟體所進行的有關於工作流程、相關工具、或相關延伸產品都要從新開發修改的話，這個成本將更為可觀！何況還有在換用新軟體間的轉換適應期，因尚未熟練或遭遇不熟悉問題而造成的工作效率下降的問題！綜合全部的考量，使得換用其它軟體的成本高昂，就算新軟體不用授權費也很難形成足夠的誘因。說到這部份，其實反而不是自由軟體的問題，因為對於這樣的公司行號而言，換用任何一種其它軟體的成本都是非常高的！

但再反過來說，如果你遇到一個從未涉入過的應用，想要找尋一套合適的軟體來處理你的問題時，就應該優先考慮使用自由軟體！對於一個從未接觸過的應用來說，不管選用什麼軟體都需要摸索、學習，自然也不存在既有資料的問題，那麼既然沒有轉換遷移的成本，在有自由軟體可選的狀況下，我實在想不出有什麼合理的理由可以不優先考慮自由軟體？唯一合理的解釋大概就是這個潛在的使用者並不知道自由軟體的存在！畢竟在臺灣，教育場所一直以來對自由軟體相關的部份付之闕如，身邊的朋友絕大部分從來沒聽過什麼自由軟體，而這也是我為什麼決定寫下這篇文章的主要原因。

此外還有一個殺手級的因素可以讓自由軟體免授權費的優勢蕩然無存，那就是盜版問題！對於一個盜版猖獗的地方，自由軟體要不要授權費其實是無關緊要的，因為在他們的觀念裡任何一套軟體都是不需要花錢買的！你又怎麼能夠在小偷強盜充斥的地方推銷正版軟體呢？

4.2 安全性

軟體的安全性其實有很多面向，除了前面提過的與軟體本身的缺陷和修補方面外，這裡我強調的是來自「惡意程式碼所造成的安全性威脅」。對於不提供程式碼而只發佈二進位檔案的軟體，你很難得知這軟體在背後偷偷做了多少事情！你覺得正常的公司不會做出這種不道德的事情嗎？那來看看下面一些「已被發現的」實際案例吧：

DOC 檔案內藏隱私資訊。 ^[13]
蘋果裝置上的後門軟體。 ^[14]
小米手機偷傳資料到北京。 ^[15]
SONY 音樂光碟暗藏後門程式。 ^[16]
美政府買通資安大廠 RSA，於加解密機制中暗藏後門。 ^[17]
NSA 要求微軟安置在 Windows 裡的後門。 ^[18]

除了正常經營的公司外，更別提那些提供「破解版軟體」的人會在裡面加什麼料了，基本上是什麼都有、什麼都不奇怪！

自由軟體的特點在這裡體現出來，因為程式碼是公開的，懷有惡意的人很難能夠在裡面偷加料而不被發現，例如數年前發生在 OpenBSD 的疑雲就是個不錯的例子 ^[19] ！這個特點有時候也成為一些國家政府討厭自由軟體的一項重要因素，其中最有名的案例大概就是幾年前發生的 TrueCrypt 事件了 ^[20] ！道理很簡單，各種訊息加密軟體、系統都可以在開發公司的私心、或者國家力量的介入下，暗藏各種後門功能，讓使用者以為可以很安心，但事實上當某些國家真的有需要時，便可以「非常快速的」破解這些加密訊息！特別是在史諾登揭露了美國的稜鏡計劃後，這些事情更成為舉世皆知的公開秘密。而自由軟體開放不受控的特性使得其他勢力難以插手干涉，自然就成為一些惡霸國家欲除之而後快的對象！

而必須澄清的是，這並不是自由軟體才具有的優點，只要能夠拿到程式碼，就可以自己檢查、編譯程式。事實上有不少商業產品允許在使用者付出一定的代價之下提供客戶程式碼，這也是為什麼很多政府敏感單位願意使用商用私有軟體的主要原因，例如美國國防部竟然會去採購使用 Windows，但他沒告訴你的是，他絕不敢在買不到程式碼的狀況下使用 Windows！

那麼既然只要能拿到程式碼，是不是自由軟體有什麼差別呢？

在需要取得程式碼的前提下，自由軟體其實是更為廉價的方案。
除了你以外，自由軟體還有全世界數不清的專家在監視、維護；而對於購買程式碼的商業軟體，你只能憑一己之力去做所有的這些事。

4.3 調整和適應的自由度

自由軟體通常會給用戶極大的自由，當然，主要的原因是來自於開放程式碼的關係。因為有程式碼在手，用戶可以做出各種深度的修改和客製，關於這點前面已經提了不少次，相信再說下去耳朵都要長繭！但除了程式碼的因素外，還有另一個原因來自於設計思想。自由軟體主要思想是開放、自由，自然它的開發參與者大部份都有海納百川的胸襟，在開發的過程中，他們通常會本能的包容、並尊重每一個使用者的個人意識；反而商業軟體通常會比較限縮使用者的各種選擇性，一來是省得麻煩，再來是若能藉此鎖定使用者的話，何樂不為？

這就是為什麼自由軟體通常可以執行在各種環境、搭配最多的前後工作流程的原因之一。另一個表徵體現在設定調整方面，自由軟體的設定配置項目通常都很細碎，細到可能大部份的人都不知道大部份的設定項目是做什麼用的、或者大部份的設定項目對於一般人都沒有修改的需要，但選項仍然在那，就為了可能有那麼一天你會需要而存在！舉例來說，開源的作業系統在安裝時通常會檢查電腦上是否存在別的作業系統，並試著兼容它，而微軟的作業系統則認為你的電腦應該只使用他的系統，而忽視其它已安裝的系統；另比如說在 Windows 10 的某些版本上面，微軟想盡辦法的阻饒你使用 Edge 以外的其他網頁瀏覽器 ^[21] ^[22] ；又比如說 GNOME 或 KDE 的使用者即使在不修改程式碼的情況下，能夠配置出截然不同而令人炫目的桌面環境 (Search for Compiz by Google)，但在 Windows 或 Mac 上你能夠調整的幅度極為有限！

4.4 長期的資料保存與銜接優勢

在資歷保存和數位永續的切入點來看，使用自由軟體能夠給予使用者長久的保障，而這才是我覺得的使用自由軟體的最重要好處！有關於數位永續的議題我已在我的前一篇文章裡詳細論述過 ^[12] ，簡單來說，選擇了私有不公開的數位資料格式做為資料儲存和交換的依據的話，會演變成對特定廠商甚至特定軟體的依賴，而長遠來看這將令使用者陷入極為不利的處境。因為對特定產品的依賴，使得即便市場上出現了更適合的產品，你也沒辦法跳槽；此時就算其他品牌的產品更便宜更強大，你對於所依賴廠商的任何不合理的索求，基本上也沒有任何反抗能力；若不幸的這個廠商有一天不復存在了，將極有可能令你的資料進入萬劫不復的境地，依資料複雜度而言，甚至有可能連花大錢解決問題的機會都沒有！

因此用戶若能向廠商購得資料儲存格式或交換協定的文件資料、甚至是得到程式碼的話，將能夠為自己留下極大的自主性和後路。而從這個角度來看，使用自由軟體不正是一種極為廉價的解決方案嗎？同樣因為自由軟體參與者通常都主張開放自由的關係，自由軟體對於公開的標準通常擁有一種接近偏執的愛好，這又讓自由軟體的使用者更有保障，因為大多時候用戶並不需要去研究修改程式碼，就能夠在好幾套符合標準的軟體解決方案中自由切換。以網頁瀏覽器為例，Firefox、Chrome、Safari、和 Opera 等瀏覽器的使用者大多自由的互相跳槽來去，但一些當初依賴 IE 和 .Net 與 ActiveX 所建置的網站卻讓使用者沒有使用 IE 以外瀏覽器的選擇！

5 使用自由軟體應有的心態

在了解了自由軟體是什麼、並明白自由軟體的各種優缺特性後，基本上你已經具備足夠的知識去使用或評估自由軟體。接下來我要寫一些關於心態上的認知，好讓大家在使用自由軟體時能夠先有良好的心理建設，至少在遇到一些令人氣餒的問題時能知道不該罵誰而應該怪誰。

5.1 當本地語言翻譯不足時

對於各種軟體，我想最常成為使用者跨入障礙的應該就是語言翻譯的部份了！不管多麼強大、或者多麼簡單的軟體，只要它沒有中文語言版本，是不是就很容易讓人望之怯步？而對於自由軟體，可能還有一些更讓使用者心情起伏的狀況，比如說中文翻譯不完全，介面中仍含有大量英文；或者是有簡體中文版本，卻沒有正中文版本！

一般面對這樣的狀況，人們可能容易埋怨開發商不推出自己語言的版本，甚至責怪說為什麼在語言上被大小眼對待，比方說同樣是中文卻只提供簡中版本。對於商業軟體，這樣的抱怨是合理的；但對於自由軟體，我們不能抱怨任何人！如同我們從前說的，自由軟體主要依賴一群志願者的貢獻，因此，自由軟體的本地翻譯不足時只代表了一件事，那就是與你同語言同文化的人裡面，很少人在使用這套軟體、要不就是沒有人願意做出貢獻。那麼，你覺得應該要歸咎於誰呢？

在使用自由軟體而遇到和語言有關的問題時，不妨想想其他與你相同語言文化的使用者是不是也會感到困擾？若是你有空閒有餘力，是不是願意提供比較正確完整的語言翻譯好造福自己的同胞呢？如果你下次看到軟體只有簡中版本，這代表了大陸人熱衷於此，而臺灣、香港等地沒有人願意付出，那麼與其抱怨，何不化悲憤為力量，互相較勁，把它變成良性競爭的動力？

5.2 當軟體不符自己期望時

與翻譯不足的情況類似，當你使用自由軟體而感受到任何功能或其它部份的不足時，其實你可以有更積極的做法。請常記得，自由軟體是大家一起付出的產物，因此若您有什麼不滿足的地方，也可常常思考自己是不是能夠貢獻什麼？若你有能力，不妨多付出一些，使它更完整，也造福群眾；若你沒有能力，也可以提出你的意見、願望、遭遇的問題等意見回饋，好讓有能力的人能夠得到更多實際的資訊來完善開發；若你仍然不能滿足，那麼也許這套軟體還未成熟完美到可以符合你的需要，也許它還需要一些時間機會來慢慢茁壯。時間寶貴的你當然可以有選擇其它軟體的權利，當然可以自由的來去，只是注意應當收起漫罵，畢竟你並未支付報酬給任何人不是嗎！

5.3 當程式可以正常運作時

若很幸運的，某套自由軟體在你的裝置上能夠正常運作，甚至能夠流暢執行而沒有遭遇任何問題的話，請不要把它視為理所當然！我想對於大部份的個人用途上，你應該沒有為這套軟體付出一分錢，而這套軟體卻是多少人無償的共獻出自己的心血，才能讓你順利的運用它來處理你的問題。下次當你意識到所使用的軟體可以正常的工作而沒有給你加添額外麻煩的時候，不妨在心底深深的感謝所有為了眼前軟體而付出的人，就是那些與你素未謀面、勞心費力，卻讓你可以輕鬆享受一切的人們。常懷感恩的心，並期許自己有一天也可以為大眾、特別是自己的同胞做些什麼事情。

6 我可以為自由軟體做什麼？

正所謂人人為我、我為人人。若你有幸使用自由軟體，並且覺得受益良多的話，除了感激以外，你還可以有更具體的回饋行動。但是因為大部份的人不了解自由軟體生態，當心裡出現想要造福眾人的一把火時，卻不知道自己能夠做什麼？這情況可能讓有些人心裡鬱卒，因此，我下面要來列舉一些可能的實際回饋方案供讀者做為參考。

6.1 加入開發行列

如果你對這軟體有很多想法、並且也擁有改變的實力，那麼何不介入程式的開發，直接提供你的強力貢獻來造福同胞？自由軟體界如果能有更多像你這樣的人共同付出的話，一定會進步神速的！與其嘴上抱怨程式如何的不令你滿意，那就來改吧！做出你滿意的樣子，再回饋給社群。

另外這裡要特別提醒一點，大部份的人可能會把開發和寫程式畫上等號，但這是不對的！自由軟體的開發固然需要人去寫出不少程式，但是對於美術、操作介面、語言翻譯、流程設計、和測試等等的人員的需求一樣急切！除了寫程式以外，如果你善於繪製程式所需的各種圖示、背景等、或是願意提供本地語言翻譯、或是願意測試並回報程式的各種問題、或是還有其它你認為能夠貢獻的地方，都可以嘗試著去做付出。

在你下載到程式軟體的網站，應該也能找到連繫開發團隊的方法(通常是透過電子郵件)，可以大膽的主動聯絡並加入有關的討論。而對於測試回報等狀況來說，情況會更簡單一些！有些平臺有架設缺陷回報系統，你只要填寫並送出即可，而有些平臺可能會需要在討論區內提出所遭遇的問題來做為回覆報告。

6.2 提供意見與回答問題

如果你已經使用某套軟體好一陣子，自認對這套軟體足夠熟悉了，那麼你也可以在社群網站上、或是各個討論區內解答回覆其他使用者對這套軟體的各種疑難雜症，這會節省許多人大量的時間精力，也會讓不少人直接感激你所做的付出！如果你當初在入這套軟體的時候，也從不少前輩那裡得到幫助指引的話，那麼請時常想著這些畫面，思考初學者的處境，這會讓你在面對一些可能令你發狂的白痴問題時可能會派上用場！如果你從前沒有任何的前人可以取得幫助的話，要不就是軟體太簡單、要不就是你極度聰穎以致不需要其他人的幫助，要不就是這表示你是走在這軟體生命週期前端的時代開創者，不管是哪一種，你其實可以從你開始站出來，做為第一代的資深前輩來庇蔭後進。

除了面向使用者以外，你還可以轉而面對開發者。做為一個資深用戶，向開發社群提供你站在使用者端所看到聽到和體察到的各種有用意見，或者提供你的各種看法或期望。做為開發團隊的眼睛與耳朵，以不同的角度提供開發團隊不同視角的訊息，使開發成果能適合更多的使用環境。

6.3 贊助

除了直接介入程式的開發維護工作或者服務支援外，還有一種方法比較不需要讓人勞心費力，那就是直接提供金錢上的援助！

雖然大部份的自由軟體讓人無償下載使用，但不代表他們不願意收受金錢。社會大眾的捐助款項可以用來補貼開發人員、或是支付一些正職開發人員的薪水、以及支應其他行政推廣人員費用、或用於分攤辦公室場地相關成本，特別是對於由 XX 基金會所維持的維護組織而言，這些捐款會很有幫助！

因此若你想要回饋自由軟體，卻沒有太多能力或時間的話，也可以透過贊助的方式做為幫助。有些軟體可以在下載頁面附近找到捐款贊助的選項，請大膽點下去，並依據個人的意願撥款給開發維護團隊吧！

6.4 使用它

幫助自由軟體其實還有一種很簡單又不費力的方式，就是去使用它！

即使沒有能力或沒有心力參與任何與自由軟體有關的工作，我們也能夠透過使用自由軟體來給出幫助。僅僅只是使用自由軟體就能夠幫助自由軟體，這怎麼說呢？再回到我一開始舉的部落格文章的例子，世界上那麼多人耗費心力寫作豐富內容的文章放上網路供人無償閱讀，圖的是什麼？又什麼樣的狀況可以激勵這些志工作者更賣力的寫出更多東西呢？不就是每一個作者都希望有更多的人來看他的文章嗎？那麼在自由軟體上面又何嘗不是如此？對於一套自由軟體，愈多的人去使用它，就能讓開發者擁有愈多繼續做出好成品的動力；愈龐大的使用者群體，也能給予開發社群更大的使命感，督促大家兢兢業業的開發出高品質的程式、和眼光更為長遠的設計。

同樣的概念再延伸下去，推薦其他人使用自由軟體、並推廣自由軟體的概念，讓更多的人接觸並了解自由軟體，一樣是每個人可以為自由軟體所付出的極大貢獻，其功勞並不亞於參與開發和捐款贊助以及以其他方式提供幫助的人！

所以請不要認為自己沒有為自由軟體做出什麼付出卻無償使用而心懷愧疚。請大膽的使用它、把它介紹給親朋好友中可能有需要的人，這個付出就足夠大了！當使用人數愈來愈多的時候，假以時日，你會發現手上的自由軟體變得更強大也更好用！

1. 「The Free Software Definition」, GNU, 連結

2. 「自由開源軟體授權條款的三分法」, 自由軟體鑄造場, 連結

3. 「五種開源授權規範的比較」, InspireGate, 連結

4. 「常用自由軟體」, 教育部自由軟體數位資源推廣服務中心, 連結

5. 「Xvid」, 維基百科, 連結

6. 「李家同他是怎麼拿到電機及計算機學位的啊-_-」, 沒見過壞人嗎？, 連結

7. 「那些台灣軟體產業所缺少的 – 開放源始碼」, 程式設計遇上小提琴, 連結

8. 「自由軟體運動」, 維基百科, 連結

9. 「Linux 桌面两大阵营 GNOME 与 KDE 的战争」, 阮一峰的IT笔记, 連結

10. 「Why is Microsoft contributing to the Linux kernel?」, Quora, 連結

11. 「Why does microsoft contribute to the Linux kernel?」, Jonas Stein, 連結

12. 「數位時代需要面對的困難：資訊保存與接駁」, 伊蜜澤瑞, 連結

13. 「.doc檔洩露機密」, 毛慶禎, 連結

14. 「蘋果電腦的 iOS 7 MDM 及其他監聽陰謀」, 資訊人權貴ㄓ疑, 連結

15. 「小米手機偷傳資料到北京？iThome找資安專家實測：有」, iThome, 連結

16. 「電腦支援 Windows 10, 小心廠商沒收你的開機鑰匙」, 資訊人權貴ㄓ疑, 連結

17. 「美政府買通資安大廠 RSA，於加解密機制中暗藏後門」, Wayne 韋恩筆記, 連結

18. 「NSA 要求微軟安置在 Windows 裡的後門… 保護智財，無可奉告」, 資訊人權貴ㄓ疑, 連結

19. 「OpenBSD 並沒有內藏 FBI 後門; 值得關切的是神秘版的 RSA 加解密演算法及 SecurID」, 資訊人權貴ㄓ疑, 連結

20. 分析一下 TrueCrypt 之死(自杀 or 他杀？)，介绍一下应对措施, 编程随想的博客, 連結

21. 「就是不給你選！微軟限制 Windows 10 S用戶更改瀏覽器及搜尋引擎」, 高敬原, 連結

22. 「微軟仍不願你在 Windows 10 輕易更換預設瀏覽器為 Chrome、Firefox」, 陳冠榮, 連結

數位時代需要面對的困難：資訊保存與接駁

Thu, 29 Mar 2018 00:00:00 +0800

數位產業有不少方便或迷人之處，我想這不需要我多說，生活在數位時代的大家應都有體會；但談到數位資訊的特性，特別是一些限制與困難，好像又沒多少人清楚！這裡為大家分享我對這個議題的一些觀察與心得，當中我覺得與社會大眾最相關、也是這次想要深入討論的兩個內容分別是：數位資訊的資料保存、及數位資料和工具的轉換遷移，且聽我娓娓道來。

從我大學時代對程式設計產生興趣到現在成為程式設計工作者大概也十多年了，慢慢的有一些自己的經驗和感想，也喜歡和朋友們討論分享 (雖然大部份時候是我單方面分享比較多，畢竟身邊朋友中了解數位內容的比例也不高)。我體認到數位資訊產業存在一些重大的且與大眾切身相關的問題，然而大部份的人似乎完全無感！於是興起了寫作勸世的念頭。之後我將會用幾偏文章來分別闡述數位資訊有關的一些比較重大的問題，可能也會提出一些解決方案，給有緣看到的人做為了解與參考。也希望有其他感想或指正的人不吝給予意見回饋。

數位資料的保存

數位時代帶給我們這一代的人很多驚奇的感受，在上個時代理難以想像的大量資料竟可以被儲存在體積如此嬌小的磁帶、硬碟、光碟、甚至是僅如手指大小的快閃記憶體等儲存媒體上！然而，你知道數位時代的資料與從前相比卻是脆弱無比嗎？數位資料都以極其微小電子、化學、或物理變化刻錄在某種物理材質上，為了大量儲存資料的緣故，這個尺度非常的小，並且未來還要更小；儲存元素的排列非常緊密，並且未來還要再更緊密。這樣的特性使得資料的長時間保存變成一種艱難的任務，至少和傳統儲存媒介比較起來困難不少！雖然說傳統紙本的資料保存方法也會有例如遺失、受潮、火災等損毀，但這些損失通常是局部性的，有些遭受損壞後的資料重建工作也不致於完全無法進行；然而數位資料往往能夠因為局部的小小缺陷而造成全面性的資料損毀，並且在大部分的情況下，受損的資料無法復原、無法識別！試著回顧一下自己、以及身邊親朋好友的數位資料使用經驗，就不難發現此一特點！

還好數位資料還有另一個與往常不同的特性，那就是資料複製幾近無成本，於是備份資料便成為解決這個問題最常被提出來的解決辦法了！然而在跌跌撞撞中，人類也發現並不是有備份就能萬無一失！面對不同類型的威脅，所需要的備份對策也有些許不同。例如鏡像磁碟解決了因為機件老化而造成的資料遺失損毀問題；但對於經由病毒或外部入侵破壞、甚至是由於使用者錯誤操作而造成的資料誤刪問題卻無法防禦！因為所有的磁碟針對一個磁碟操作指令都會在同一時間內同步進行。於是保險的數位資訊的保存系統還必須要加上有關時間版本的備份、控制、查詢、和回復等功能；然後一個雷擊下來，機房全毀，所有資料保存機制全無作用！

大概就像這個樣子，現今發展出來比較完善的備份機制除了資料冗餘外，還要加上異地、異質、以及時間版本存檔等。

但是還有一個數位資料的大殺器直到現今依舊沒有良好且能夠普及的對抗方式，就是電磁脈衝！短暫而強烈的電磁脈衝足以燒毀由極細緻電子電路所構成的電腦晶片等設備，當然也就能夠造成數位資料的全面性毀損。大的電磁脈衝可以在核彈爆炸、以及專為產生電磁脈衝風暴而製做的電磁脈衝炸彈爆炸時產生。講到這裡也許很多人鬆了一口氣，畢竟很多人認為戰爭發生在自己生活的地方這件事是很難想像的，但是，大自然其實也會發出足夠強大的電磁脈衝，例如太陽風暴！太陽有時會發出非常烈度不一的電磁風暴，當它打到地球時，輕則造成無線電干擾，重則損壞電力設備。 1859年9月就發生過一次，造成歐美的電報系統和電力系統異常，這次事件稱為卡靈頓事件； 1967年5月也發生過一次強烈的風暴，使冷戰時代的美國飛彈預警系統全面失靈； 2012年7月，強烈的太陽風暴幾乎就從地球旁穿過(宇宙尺度)，果真如此，別說電腦了，當今的一切電子設備將全部歸零！說實在的，就從有人類開始算起，強烈太陽風暴打到地球上早就無數次了，但因該重來沒有哪個時代的人像現在這樣的害怕太陽風暴吧！

雖然現在已經開始有軍用電子設備要求能夠防範電磁脈衝的破壞，但畢竟這樣的設計還未普及於大眾，因此可說在甚至十年內，人類社會對於太陽風暴所造成的資料設備損毀是完全沒有任何招架力的！你知道嗎？網際網路的發明者直到現在仍使用紙本方式在保存自己的照片呢！ ^[1]

總之，面對數位資料的保存問題，首要要有的認知是沒有儲存媒體是真正保險的。最重要的重點就是備份、備份、再備份，這不是什麼新的方法概念，但問問自己，有多少人好好做到「備份」這件事？ ^[2] 其實只要多做備份、勤做備份，就能避免絕大多數讓資料全損的機會；至於不可抗拒的天災？目前還沒有任何現實的方法對策，只能聽天由命了！

數位資料和工具的轉換遷移

數位資料、和數位產品還有一個在以往的時代難以想像的巨大成本：「轉換遷移成本」。

我們應該都知道「購入成本」，就是買一個東西進來的成本，這是大家最熟悉的成本；隨著工業時代的到來，人們開始關注到包含維護保養等在內的「壽期成本」，體認到有些購入成本比較低的東西不見得真的比較便宜；到了數位時代，大家漸漸發現「轉換遷移成本」才是最恐怖最昂貴的成本！什麼是轉移成本？我們原本使用一個東西，後來改用另一個東西，為了使用這另外一個東西所需要付出的成本就是轉換遷移成本。比方說一張椅子，今天基於任何緣故我買了另一張椅子來替換這張椅子，除了要花錢買之外，兩張椅子坐起來的感覺不一樣、佔用的空間不一樣、顏色不一樣等等，都需要花時間心思去適應，這就是買別張椅子的轉換成本。同樣的，換車、換房、換工作、換學校等等都需要轉換遷移成本，只是這個成本一直以來可能低到不被人所關注，通常只在像國家軍隊要換用不同口境槍彈、要購買不同系統的戰機時，轉移成本才會大到讓人注目。

然而對於數位資料與相關產品，有些人可能已經經驗過，「換用別的東西」這是多麼困難的事情！我們通常不能、或難以像更換不同品牌型號的汽車駕駛，或是像更換不同品牌型號的辦公桌和文件櫃那樣來更換使用不同的數位產品，特別是軟體產品。造成這種現象的主要原因有二：

軟體操作設計的差異

不像汽車雖然每個廠牌型號都不一樣，但主要的操作結構卻大同小異，一通百通。至少你沒看過排檔桿在頭頂上的車子、或是排檔桿不是前後推拉而是左右推拉操作的車子吧？或是A車油門用腳踩、B車油門用左手推、C車油門用右手操作，並且往外拉是加油而往內推是減油的車子？但是不同廠牌型號的軟體，其操作介面往往大相逕庭！這是設計思想或應用環境的考量，通常不能說誰對誰錯，但卻往往造成熟悉其中一套軟體的人在轉而使用另外一套軟體時(甚至很多時候其實是同一家廠商的不同版本) 的巨大學習阻力！

對於操作方式不同的這個問題，站在使用者的角度能夠選擇的方法不多，除了死巴著某個型號版本不換以外，就是改變自己去適應不同。保持一個開放的心態接納不同軟體的不同操作方式，對於當中遇到的挫折，大部份其實並不是另一套軟體不好，只是設計的不同罷了！提醒自己時時充滿學習新事務的心態，比別人更快的掌握新的知識技巧，誰叫我們剛好生在數位科技日新月異的年代！

對於軟體開發商，看似他們才是是能夠解決操作問題的主要角色。但就像我說的，大部份的設計差異是設計概念或應用環境的不同而造成，硬要強迫大家做成一樣的長相也未必是好事。我舉個例子，若是把智慧型手機與桌上型電腦的文書處理軟體做成一樣的介面和操作方式，我想不會有人認為這是好的吧！又比如說如果我們要讓 Mac 和 Windows 電腦上的軟體介面一致，那我們都可以想像到兩家公司跳出來吵架的畫面， Microsoft 一定說 Mac 要改成和 Windows 一樣，畢竟 Windows 使用者最多；而 Apple 一定跳出來說我們的 UI UX 設計是最好的，為什麼要和垃圾般的 Windows 一樣？應該是 Windows 要改成和 Mac 一樣才對！

不過撇除這些因為應用環境或設計理念而必須的不同，在其它地方上不同廠商的確有漸漸做得一致的趨勢，而且小廠商對於這件事更加賣力，畢竟減低客人轉換使用自己軟體的成本對於自己是有利的！反而對於大廠商，特別是那些市佔率超高的大廠商，往往挾著擁有龐大死忠客戶的支持，恣意變更軟體操作介面，每次改版弄得客戶哀聲四起也豪不在乎！畢竟增加客戶轉而使用其他對手產品的成本，這對於自己是更有利的！

檔案資料格式的問題

討論完前面提到對於軟體「操作使用」的問題後，另一個更大的問題就在於「資料格式」(包含通訊協定，下同)。通常很少有軟體不需要計算處理、存取、或收送任何「資料」的，而這些資料如何被保存交換？不像傳統紙本書面資料，不論筆不同、墨水不同、筆跡不同、還是紙張不同、甚至是書寫格式不同，這些通常都不會在資料的交換、閱讀、或保存上有什麼困難；數位的資料就是一大堆「0」與「1」的排列(我們一般稱為「二進位格式資料」)，基本上沒有人能夠直接閱讀然後讀懂！數位資料的閱讀以及編寫，人類永遠需要透過「軟體」來進行，而軟體如何將人看得懂的資料轉換成二進位資料，以及如何將一堆二進位資料轉換回人可利用的資料，這就牽涉到所謂數位「資料格式」的問題。事實上資料格式的問題並不只存在於人與資料之間，若不同的軟體之間需要交換資料也會面臨到此問題，比如說使用繪圖軟體製做一個圖片檔，然後使用文書軟體利用這個圖片檔，那麼這個文書軟體就需要知道如何解析圖片檔案並加以利用。

一直以來，軟體的資料格式都是做軟體的人自己決定、自己設計的，於是若不使用同一套軟體，人沒有辦法解讀二進位檔案的資料！除非你能拿到這套軟體儲存資料的格式規格文件，然後照著它重做讀寫解析；或者走向更慘烈的道路：使用逆向工程方法研究破解該資料格式，然後重製資料讀寫功能！這導致了兩個嚴重的問題：

不同軟體之間的資料共享變得困難重重。
比如說讓文書軟體利用繪圖軟體產製的成品、或讓影片播放器播放影片製做軟體產製的影片、或讓網路瀏覽器能夠閱讀網站伺服器的網頁等等，都變得難以實現，除非你所使用的一系列軟體全都出自於同一個開發商。 ^[3]
對特定軟體的依賴。
若某個軟體所產生的資料只有該軟體能夠正確的加以讀取利用，則代表使用者沒有辦法換用其他的軟體來執行同樣的工作，除非使用者願意捨棄其重前所擁有的數位資料，然後使用新軟體重新開始！這導致隨著使用者所累積的數位資料愈來愈多，使用者對某特定軟體的依賴將愈來愈深，而成為死忠支持者；不同於政治上狂熱的死忠支持者，這種的軟體死忠者往往是迫於無奈卻又離不開！ ^[4] ^[5]

數位產業剛開始發展的時候，說實在的沒有人想到這個問題，因此引發了一些悲慘的事件！要解決資料格式所導致的問題，就要讓軟體公開自己的資料格式規格定義、或者讓軟體改使用某種共同的資料格式，在透明格式或共同格式的基礎下，其他軟體就能夠依循共同的規格來交換文件或利用其資料。不管共同資料格式來自於國際公正機構的制定或是大頭廠商間的妥協抑或其它，標準、透明、通用的資料格式對使用者是福音，對產業的競爭也是良性的。以文書處理軟體為例，在基於共同格式標準的前提下， A 品牌的軟體所編寫的檔案便能被 B 品牌的軟體正確開啟並加以編寫，反之亦同。這樣，消費者可以依據自身的需要選用最合適的產品，有些軟體受擁戴是因為超級複雜強大；有些軟體受青睞是因為功能雖陽春但以體積小巧玲瓏，可以在任何運算資源稀缺的裝置上正常運作；有些軟體受惠顧是因為功能雖不豐富但操作介面簡單易懂又符合直覺，適合非專業人事入門使用；有些軟體受喜愛是因為沒什麼強處但 UI 設計粉紅又可愛；有些軟體受特定領域人士愛用是因為它某個特定領域的工具特別充實完善；還有些軟體…… 不管怎麼樣，這不就是一個產業的競爭應該要有的樣子嗎？比如說汽車市場。

但是，通用格式卻會傷害到老牌又擁有市場規模的既得利益軟體廠商的利益！這些廠商的軟體產品在早年也許真有兩把刷子，又因各種緣故佔到市場先機而奪得廣大使用者的愛用。但時過境遷，現在它們的軟體已經沒有以往那麼叱吒風雲，又或者現在的使用者只是很單純的不想要被綁死在該廠商的軟體上。不管是哪一種理由，讓消費者對別人投懷送抱一定會損害到自己的收益，於是不管道德不道德，在資料格式上搞鬼變成綁架使用者的有效方法，使其成為公共標準格式推行的最大阻礙！ ^[6]

透過在資料格式上搞鬼來鞏固消費版圖？這是如何做的呢？這裡不說太多細節，我只說原理：假設有 A、B、C、D、E 五家廠商共同遵守標準，他們所產製的資料都完全可以交換利用，使用者也可以依其喜好或需求選用任何品牌。這時某家 Z 廠商決定不合作，你們遵守標準是你們的事，我就是要使用我自己制定的私有格式，任何人來用我的東西就是要遵守我的規則；甚至更壞，Z 廠商表面上與大家合作使用共同格式，但實際上他對這種格式的細節認知與大家不同。這會導致 A、B、C、D、E 所產生的資料互相交換都沒有問題，就只有在與 Z 交換資料時會有問題！理論上 Z 應該會被大家唾棄，然後從市場上消失；但這裡不要忘了一個前提，Z 在此之前已經擁有了大部份的市場份額，於是結果完全相反！在大家都用 Z 的狀況下，若有一個人因為個人喜好或其它因素使用了 A 軟體，那麼這個人必然被群起圍攻，因為大家一直以來不曾出過問提的互動模式(Z-Z 資料交換理論上不會有問題)竟然在 A 身上出了錯，誰要為此負責？我想結果是很明顯的，對於一群不懂數位也不明白大廠壟斷問題的一般使用者而言，是不可能會把問題怪到 Z 身上的！於是 Z 廠商就這麼坐收一大群支持者在第一線幫他鞏固了市場利益，而最後被邊緣化的反而是那些其他品牌的軟體！你說這些理論太難懂，想要問實際的案例嗎？回頭想想當年無人不知無人不曉的 IE6、還有每次一改版就搞得大家格式不相容的歷代 Office 也許就能理解了。

為什麼我們需要在意數位轉換問題？

有些人會說：我又不懂數位什麼的、我也不寫程式、也不會去經營軟體公司，那些壟斷什麼的、公開格式什麼的和我有什麼關係？至於被特定軟體綁住？我從前就一直使用這套軟體，也沒有對我造成什麼問題啊！未來我還是會繼續使用這軟體，難道又會怎麼樣嗎？於是接下來我就要解釋高昂的數位轉換成本為一般市井小民而言有什麼嚴重的後果，以及目前有什麼解決方案。

放任使用除開發商外無法解析的資料格式來做為資料保存的依據，將使自己所累積的資料必須依賴特定品牌軟體(甚至是特定版本)才能夠正確的存取使用，使得對軟體產品的的選擇性受到極大限制，即使市面上產品種類多樣，但你心理知道你其實只有一種選擇，除非你願意放棄數年下來使用這套軟體所累積的資料！這些是我們已經知道的部份。

當消費者在事實上沒有軟體使用選擇的時候，你將任軟體廠商宰割，他對你予取予求而你只能全盤接受！如同 Scott McNealy 在演說中以企業所使用的資料庫系統做為例子的形容：

因為一旦你開始採用 DB2 的語言，拿它來開發你所有的應用軟體，訓練你的員工、開發相關的輔助工具、 … 你開始把你所有的資料鎖進一個私有專屬的語言，而這種語言的字典/文法/教科書/…的鑰匙完全掌握在 IBM 的手上，然後你就玩完了！ ^[7]

— Scott McNealy
PG West 2010: The Barrier to Exit

你可以想像當你第二次想要購買新版本系統的時候，人家開多高的價錢你都得付，因為你事實上並沒有選擇其他軟體的可能性，除非你願意把過去所累積的所有資料、包含建立於其上所建立的週邊軟體、以及一切的教育訓練、已經熟練技能的員工等等，都當作從未有過一樣讓它煙消雲散！當然，有些人會說我有選擇的權利，我可以不買啊！雖然我沒辦法換用別的系統或軟體，但原來買的這一份運作的很好，我為什麼一定要換呢？這說的太好了，事實上這的確是一個很常見的因應對策，這就是你為什麼可以在很多的公司行號機關單位裡看到老舊到不能再更老舊的軟體系統的原因！但其實這麼做只是延後付出代價的時間而已，首先你無法享受到隨者時代的進步而改進或新增的各種或方便或酷炫的功能，而只能把自己定死在某個固定的軟體版本上；在者，你的硬體設備總有一天會壽終正寢而需要更換，但隨著時代的推移，這些老舊軟體所建基的執行環境(比如說舊式作業系統或舊式規格硬體設備等)會愈來愈難以取得。於是你需要出高價來購買市面上稀缺的、僅存甚至可當古董的老舊設備來延續軟體系統的使用，或者終究還是得回頭找原來的軟體開發商求救，當然這時候的價錢依然是人家說了算！

不過上面的情況其實不是最壞的，到頭來你還會發現能夠用錢解決的問題終究不是最嚴重的問題！還有另外一種狀況是當你需要原軟體開發商的奧援，即便需要支出大筆金錢也在所不惜時，原來的開發商卻早已不復存在！現在有一個詞用來形容這樣的現象，叫作「軟體孤兒」。這種狀況下你只能抱著現有的軟體系統，過一日算一日，期待整個系統完全死掉無法復生的日子永遠不會到來！下面有一些真實的例子給大家做為警惕：

2001 年，美國南加州大學神經生物學和細胞學專家 JosephMiller 博士向美國 NASA 尋找 70 年代中期探測火星的維京(Viking)計劃中獲得的資料時，發現這些有 25 年歷史的資料是以專用格式保存在磁帶上，而當時撰寫記錄這些資料程式的工程師已經去世，因此這些資料實際上已經無法讀取。 ^[8]

— 洪宗勝
國家衛生研究院電子報

2006 年本人已經無法使用 1986 年自己所撰寫的科技論文，因為那篇論文是用一套叫做 WordStar 的軟體完成的，而 WordStar 的軟體已不復存在。 ^[8]

— 洪宗勝
國家衛生研究院電子報

簡單來說，過度依賴特定數位產品會造成兩個嚴重後果：第一是對於單一廠商的索求威脅沒有抵抗的能力，全然無法守護自身利益。舉個例子，看最近這兩年 Windows 10 的強勢推出讓所有人罵得要死，但是除了罵之外還能怎麼辦？事實上下回要再強勢推出 Windows 11 的話，這些人罵歸罵，還是會買的！第二是對於資料的長久保存不利，對於過了二十年後能不能再回頭檢閱、甚至重新利用舊的檔案成了嚴重的問題；更慘的狀況可能是這個廠商已不復存在，讓你連花大錢解決問題的機會都沒有！

我見過有些個人面對這樣的威脅依舊無感，就我的經驗，這些人要不極度沒有危機感，要不就是本身沒有什麼重要的數位資料，以致失去也無妨；然而對於很多企業、特別是國家單位或組織而言，這個問題是極其嚴重而且不能被忽視的，因此這些單位對於數位資料的永續性議題一直非常關切！至於臺灣的公司為什麼普遍沒有數位永續的概念？據統計，臺灣中小企業平均壽命約 13 年上下，也難怪不在乎！而對於讀者你，除非你是比較習慣使用紙本資料的老派作風^[1]、或是覺得自己的餘命大約只有十年上下，否則數位資料和工具的永續性議題一定是你會需要擔心的事情。

該如何面對數位資料與工具的永續性問題？

讓數位資料能夠永續保存利用的最根本方法，就是制定資料格式標準，並依循標準。關於這點的解釋前面有說明過，不再贅述。不妨從現在開始要求自己，對於任何數位資料的傳遞交換或保存都儘量使用標準格式或開放格式 ^[9] ^[10] ^[11] ，例如，能夠存成 DOT 或 PDF 檔的東西就不要存成 DOC 或 DOCX 檔；能夠存成 SVG 檔的東西就不要存成 AI 檔；能夠存成 IGES 或 STEP 檔的東西就不要存成 DWG 檔；能夠使用 HTML5 實現的功能就不要使用 Flash 或 ActiveX 來做；能夠使用其它電子郵件軟體的話就不要使用 Outlook 來收發信等等。在這點上，使用自由軟體會是一個不錯的選擇！雖然自由軟體是另外一個概念，但基於某些原因，自由軟體通常都極力於遵循標準或公開格式。使用標準格式或開放格式來交換資料，資料收送兩端可依各自的考量選用處理的工具；使用該格式來保存資料，則即使數年後原先使用的軟體已不存在或已無法使用，你依然可以改用其它同樣支援標準的工具來處理；若該資料格式過於冷門或已不再被使用以致找不到可用工具，由於規格書是開放自由的，你還可以透過規格書自寫解析器；若你不會、或不想做這件事，還可以花錢交給別人來做；但是對於不公開的專有格式，除了拜託原廠(如果原廠還存在而且消費者負擔得起)或透過逆向工程來破解外，別無它法！

然而在在實際執行層面上，使用標準格式或公開格式的解決方案往往會遇到極大困難，其中最大的阻力來自於既得利益廠商的刻意掣肘，舉例來說：對數位時代的人來說，最有機會使用、也最有機會碰到問題的數位資料大概就是網頁和電子文了。 1995 年推出的 HTML ^[12] 標準格式理論上可以作為各家網路瀏覽器和網站伺服器共同遵行的依歸，然而在微軟利用其既有龐大市佔率的刻意不合作下，使網頁標準分裂為 W3C 的公開標準、以及 Microsoft IE6 的事實標準。這個舉動維護了旗下 IE 產品的市場，卻讓廣大網頁讀者和網頁設計師陷入混亂的愁雲慘霧中 ^[13] ^[14] ！對於數位文件長期以來一直是 Microsoft Office 的天下，但這等同於所有的文件必須依賴單一廠商產品才能夠正常使用，即便如此，新舊版 Office 之間層出的不相容問題更讓許多企業組織和國家單位深感不安！ 2005 年，OASIS 制定並發佈了 Open Document Format (ODF) 開放文件格式 ^[15] ，此舉立刻引起科技領域、企業界、以及各國政府部門的高度重視，在四年內即有 16 個國家、以及無數大小企業組織宣佈將使用 ODF 做為檔案交換與保存的標準格式，中華民國政府亦於 2009 年將該文書格式收納為國家標準(ODF-CNS15251) ^[16] 。至此各位看官大概已經猜到這件事情對誰最為不利？因此微軟又陸續打出一系列手段，包含刻意不相容 ODF 標準與強推自己的新文件標準(OOXML)來鞏固 Office 軟體的市場，增加 Office 使用者轉用其他文書軟體的障礙，也就是一般常見的所謂檔案不相容問題 ^[17] ^[18] ^[19] ^[20] 。

除了既得利益廠商的箝制使得換用標準格式或開放格式不易外，另一個困難則是目前不是在所有的應用上都存在有標準格式！這不難理解，因為總是先有應用需求產生，然後才開始制定標準；就好像總是先有相關社會風氣或問題出現，然後才開始制定相關法規一樣。因為整個數位產業還非常年輕，很多方面還沒有標準可依循，就連普邏大眾都需要的數位文件標準的出現也才是 2005 年的事情而已！因此目前在不少比較專業、冷門、或客製的應用上，不得不使用專有的軟體系統以及黑盒子般的數位資料！在這種情況下，事實上仍然有對策可用：

要求在存在有標準規格的地方必須依循標準規格。
比方說一套專用的資料庫系統，雖然目前還沒有真正可用的資料庫系統標準，但這系統總有一些地方可以銜接既有的功能，比如說列印報表時產生的是純文字檔案還是專屬的資料格式？比如說輸出圖形的時候產生的是公開的 PNG、BMP 等格式還是專有的資料格式而只能夠過專用軟體來顯示等等？這樣的做法雖不能改變主要功能的依賴性，但對於週邊工具的選用與組合卻能更有彈性，省得為了每一個可能小小簡單的功能都要仰賴廠商來實現。
要求提供規格文件。
雖然整套系統的資料是專有的，但若能夠向開發商要求、或是購買相關的所有資料格式和通訊協定等規格文件，這可以減少在未來在需要轉移軟體系統或解析資料時的龐大成本！
要求原始程式碼(當然也包含各種文件)。
要求軟體開發商一並提供、或是向其購買軟體系統的原始程式碼，這點可以給消費者帶來極大的使用彈性、自主性、和後路，在使用者需要微調、修改、或增刪功能、甚至是轉移系統的時候可以自己來做，或是付錢交給其他人來做，而不必凡事仰賴原廠。尤其當原廠獅子大開口或已查無此人的時候，有程式碼在手可以讓你自己處理需要的工作，或至少讓你擁有向第三方求助，花錢解決問題的機會；否則在沒有程式碼的情況下，依現代軟體的複雜度，要直接解析二進位檔案並搞清楚它做的事情的話，這個成本會比天還要高！
要求廠商負擔出走責任。
這是一個蠻新的概念，其實這個概念與購買產品時一併購買維護諮詢合約是一樣的，就是要求廠商必須負擔可能數年後消費者要遷移使用其它(不同廠牌)產品所衍生的工作和責任。這有兩個好處，第一是可能可以一定程度增加開發商肆無忌憚使用私有或隱晦設計的成本；第二是可以讓隱藏的轉換遷移成本提早反應在產品售價上，讓決策者在思考的時候看見這個成本。但我私心以為只有第二個好處才是真正的好處，因為對於第一點，當消費者需要轉移軟體系統的時候，該軟體供應商必須仍然存在才有可能負起應該的責任！

以上幾種做法都會程度不一的提高軟體的購買金額，往往使當代的決策者產生遲疑！這是因為轉換遷移成本還沒有被普遍認識並接受的關係，這和工業革命以後，社會大眾也花了數十年甚至百年來理解並接受產品除了購買成本外還有養護成本是一樣的！事實上不管是維護成本還是轉換遷移成本，消費者總是無法逃避。如果說購買產品時一併購買保固與維護服務是為了讓隱藏的養護成本能夠反應在售價上而被看見，進而被比較的話，那麼要求廠商負擔轉換遷移責任(當然軟體開發商會把它反應在售價上) 其實就是將原本隱藏的轉換遷移成本能夠在售價上顯現出來，進而被比較；唯要再次提醒的是，如同機器的維護保養費用一樣，不管你有沒有把這個成本列在採購金額裡，這筆支出總是需要繳納，差別只在有沒有提早讓你在帳目上看見而已！從這個角度來看，使用開放原始碼軟體其實不失為一個廉價的方案，當然這又是另外一個話題了……

為什麼數位產業會有這麼多問題？

任何新的東西都有我們所不知道的特性等待被發現、被理解，一個產業興起當然也就包含了各種未知的產業特性，其中有一些特性會成為問題與阻礙。人們會在其中摸索、試驗、改變、成長，這就是為什麼產業初期往往會出現各種型態迥異的產品、為什麼前後問世的產品往往結構大相逕庭的原因。人們也會不斷發現以往所未曾知曉的各種新問題、然後設法解決問題、並在學習中成長，直到一段很長的時間以後，產業才回慢慢穩定下來，找出一個可以穩健行走的道路，這個時間我推估大概需要兩百年至數百年不等！

讓我們回想一些我們所熟悉的產業：例如航空，從萊特兄弟帶領人類進入動力飛行的時代開始，兩百年來航空飛行遭遇了種種奇怪的、而且人類從未想過的問題，人類從次次摔飛機的人命折損中慢慢學習到了副翼和尾翼搭配的飛行控制方法、航空氣動力學、結構與疲勞、乃至飛行員特質與航空心理學等等。直到今日航空飛行算得上是穩定安全時，距離人類首飛也過了兩百個年頭；再看看建築，從跟隨師傅學習後可以自己蓋房子，到結構、管線、防火、逃生等被重視，到法規和證照被提出，又過了幾個百年？從瓦特發明蒸氣機開啟工業革命以來，工廠、流水線、乃至輸送銷售與環境污染等議題又過了多少年？直到現在仍在解決問題！再回頭看看數位資訊產業，從 1941 年第一臺電子電腦問世至今還不到百年 ^[21] ！雖然我們已經脫離 1950、1960 年代那時每臺電腦架構都大不同的時代，但仍還有不少大小問題不斷被發現、被了解、然後被處理。

對於一個新產業的興起，人們常會延續使用看起來與它相似或相關的規則和方法等，比如說航空產業就大量套用了航海業的規則慣例。將這些方法套用在不同的領域上或許會有些水土不服，然而對於一個全新的未知領域這又未嘗不是個發展的好起點！然後就在大家覺得上手愉快時突然發現一些從前的領域裡未曾出現或未曾被注意到的問題，當中甚至有些困難是源自於人所套用的「相似領域」規則慣例所造成，比方說軟體開發模式的發展就是從最早直接套用工業產品研發生產模式，然後不斷吃鱉的過程！然後人們才會從這些事情中恍然大悟說：「啊！原來是這樣子啊！」至於對一個問題的修正改進，這又是一個漫長的道路了……

提起這些是為了讓大家明白，數位資訊的大小問題通常不是誰的錯，而是一個時代的必經過程！有些問題以現在的眼光來看可能有些令人覺得不解，但在當時就是沒有人預料得到，怪就怪我們剛好生在這個數位產業還未完全成熟穩定的時代吧！

我們該如何看待數位產業的問題？

數位產業的問題只有我寫的這些嗎？答案是否定的！我自認不是時代的領跑者，沒法事先預告一些專家們還未體認到的問題；甚至就當前已知的問題裡，我也只是挑了兩個我想討論的主題而已。數位產業一定還有更多未知的問題等待有一天被發現，當中也許有一些問題甚至可能比本文所提及的更為重大！

既然數位資訊存在這麼多嚴重的問題，那我們應該停止使用一切數位產品並回復沒有電腦前的做法嗎？當然這是一個解決問題的方法，但不推薦，通常也不實際！一個新領域的興起一定是因為這個領域存在一些強大的好處、甚至還會顛覆一些傳統的領域，裹足不前不只無法享受新時代的好處，有時還會讓自己本有的優勢漸趨下風，甚被取代淘汰！比如說工業、工廠帶來一大堆從前沒有的問題，那麼我們應該要廢棄工業化，回到從前農耕時代嗎？提出這些問題的本意並不是要嚇唬人；相對的，知悉問題、正視問題、面對問題，讓你在享受數位時代的時候能夠同時了解它的各種眉角，能夠及早做好準備應對、或將影響損害減到最低，這才是應當有的態度，也是本文的目的。

1. 「網際網路之父：我都用紙張保存資料」, 鏡週刊, 連結

2. 「請不要再用行動硬碟『備份』檔案了」, 高登工作室, 連結

3. 「維護接駁資訊的權利, 消費者自求多福」, 洪朝貴, 連結

4. 「鴉片軟體」, 維基百科, 連結

5. 「自願被微軟綁架的台灣政府」, 報導者, 連結

6. 「3E戰略」, 維基百科, 連結

7. 「Scott McNealy 談資訊科技轉換跑道的成本(下賊船的代價)」, 洪朝貴, 連結

8. 「演講紀要：企業及政府機關如何導入OpenOffice.org辦公室應用軟體」, 國家衛生研究院電子報, 連結

9. 「挑軟體，你押對寶了嗎?」, 洪朝貴, 連結

10. 「沒有微軟的日子」, David Becker (陳奭璁譯), 連結

11. 「邁向自由穩健走」, 洪朝貴, 連結

12. 「HTML」, 維基百科, 連結

13. 「IE6人人喊打，你還在用嗎？拜託升級吧！」, tenz, 連結

14. 「救救設計師！請拋棄Internet Explorer 6」, 阿玻, 連結

15. 「ODF」, 維基百科, 連結

16. 「推動ODF-CNS15251為政府文件標準格式」, 國家發展委員會, 連結

17. 「為什麼微軟 Office 的檔案格式如此複雜？（以及一些解決方案）」, 約耳談軟體(Joel on Software), 連結

18. 「Office 軟體到底該用哪個？各家格式標準為何？」, 科技新報, 連結

19. 「微軟文書格式為何常跑掉？揭開 OOXML 格式大祕辛」, 科技新報, 連結

20. 「OOXML / 微軟舊封閉格式轉成 ODF — 為何不要用微軟的 Office 來做這件事？」, 好馬的部落格, 連結

21. 「阿塔那索夫貝理電腦」, 維基百科, 連結