閃爍燈程序，本人已證明該程序可以在ATtiny13A上正常運行。
#include <avr/io.h>
#define F_CPU 1000000U // 這個我是暫時亂寫的晶振大小，我也不知道現在晶振大小是多少！！！！
#include <util/delay.h>

int main()
{
    DDRB = 0xff;
    PORTB = 0xff;
    
    while (1) {
        PORTB = 0xff;
        _delay_ms(1000);
        PORTB = 0x00;
        _delay_ms(1000);
    }
}

我的熔絲位被設置成了2A FF。因為CKSEL = 10，所以晶片是使用的內部的9.6 MHz晶振，又因為CKDIV8 = 0，所以晶振進行了8分頻，因為9.6÷8=1.2，所以F_CPU應該被設置為1200000U:
#define F_CPU 1200000U

插上一個74HC595後，用Linux下的avrdude燒寫的以下程序：
#include <avr/io.h>
#define F_CPU 1200000U
#include <util/delay.h>

int main()
{
    DDRB = 0xff;
    PORTB = 0xff;
   
    while (1) {
        PORTB = 0xff;
        _delay_ms(500);
        PORTB = 0x00;
        _delay_ms(500);
    }
}
可以正常運行。運行結果：LED亮0.5s滅0.5s。
但是，用AVR_frighter保存flash內容，擦除晶片，重新燒寫保存的flash內容後，程序完全不能運行，LED完全不亮。
不過，用AVR_frighter讀寫熔絲位還是可以的。

這充分表明了：
我的推測1「因為ATtiny13的PB口不足8個I/O口，執行DDRB = PORTB = 0xff把全部8個I/O口都設置為1會引起程序故障而導致所有I/O口都不能輸出任何電平。必須要執行DDRB |= _BV(4)單獨設置一個I/O口為輸出，程序才能正常運行」 是 錯誤的！
我的推測2「74HC595晶片影響了AVR_frighter對ISP程序下載的操作導致程序不能正常下載，而該晶片不影響avrdude下載程序」 可能是正確的。

現在通過實驗證明推測2的正確性。
在ICC AVR中編寫以下程序，並用AVR_frighter燒寫：
#include <iot13Av.h> // ATtiny13A

void main(void)
{
    DDRB = 0xff;
    PORTB = 0xff;
   
    while (1) {
        PORTB = 0xff;
    }
}
程序運行結果：LED燈不亮。
把PORTB = 0xff;改成PORTB = 0x00;
再編譯，燒寫，LED燈仍然不亮！！！
這TMD還真是AVR_frighter的問題！

現在，馬上用Linux下的avrdude重新燒寫程序：
[octopus@pc3 ATTiny13]$ make run
avr-gcc -mmcu=attiny13 -Wall -Os tiny.c -o tiny.o
tiny.c:5:6: warning: return type of 'main' is not 'int' [-Wmain]
 void main()
      ^
avr-objcopy -j .text -j .data -O ihex tiny.o tiny.hex
sudo avrdude -p t13 -c usbasp -e -U flash:w:tiny.hex
[sudo] password for octopus:

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9007
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "tiny.hex"
avrdude: input file tiny.hex auto detected as Intel Hex
avrdude: writing flash (86 bytes):

Writing | ################################################## | 100% 0.76s

avrdude: 86 bytes of flash written
avrdude: verifying flash memory against tiny.hex:
avrdude: load data flash data from input file tiny.hex:
avrdude: input file tiny.hex auto detected as Intel Hex
avrdude: input file tiny.hex contains 86 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.58s

avrdude: verifying ...
avrdude: 86 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:FF, L:2A)

avrdude done.  Thank you.

[octopus@pc3 ATTiny13]$

程序正常運行！
（那個int main()寫錯了暫時不管了。。。）

筆者又把ICC AVR生成的hex文件複製到Linux下用avrdude燒寫，LED亮了！程序正常運行。

所以，ATtiny13A晶片本身沒有什麼問題。我的電路也沒有問題。問題主要出在AVR_frighter上，都怪它！以後不要再用AVR_frighter燒寫ATtiny13的程序了！
AVR_frighter燒寫gccavr和ICC AVR的程序都無法正常運行。
而Linux下的avrdude燒寫gccavr和ICC AVR的程序都可以正常運行。
至於Windows平台下的WinAVR，因為用的編譯器和linux下是相同的，所以我估計燒寫後也可以正常運行。不過我還沒有測試額。。。。

筆者又把74HC595取下來了。然後再用AVR_frighter燒寫ICCAVR程序，LED不亮。再用avrdude燒寫同一個hex文件（ICCAVR生成），LED亮。這證明：
不是74HC595晶片影響了AVR_frighter燒寫程序。是AVR_frighter壓根就沒法正確地燒寫ATtiny13晶片！

另外，4~13樓的程序中所有的int main()都改為void main(void)，筆者疏忽了，不過也不影響程序的編寫。