闪烁灯程序，本人已证明该程序可以在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)，笔者疏忽了，不过也不影响程序的编写。