火鸟测评：这些坑先看
火鸟测评不能只看安装包多小、跑分多快。我更关心三件事：交付给客户会不会出问题，数据坏了能不能救，团队接手会不会骂人。下面按真实搜索问题回答，顺手把我见过的误区拆开说清楚。
Q：火鸟到底适合什么项目？
适合边界清楚的业务系统：单店收银、设备采集、内网报表、桌面管理软件、离线优先的小工具。它的优势是轻量、授权友好、嵌入式能力强，不需要为了一个 5 人办公室系统拉一整套数据库运维。
不适合边界很虚的互联网项目。你要弹性扩容、读写分离、云厂商托管、海量插件、招聘现成 DBA，火鸟不是舒服选择。很多差评不是火鸟不好，而是把它放错了工位。
Q：性能是不是比 SQLite 强？
这个问题要分场景。SQLite 的单文件体验更极致，本地读多写少非常顺。火鸟更像一套完整关系型数据库，有服务端模式、事务、存储过程、触发器，多个客户端访问时更有章法。
我做过一个导入测试，几万行批量写入时，索引、事务批次、提交频率比数据库品牌更影响结果。每插一行提交一次，谁都难看；一千行一批提交，火鸟表现会正常很多。
Q：新手最容易踩哪个坑？
第一是字符集。库没用 UTF8，客户端又乱设编码，中文字段迟早出事。第二是路径。远程连接时数据库路径是服务器上的路径，不是客户端本地路径。第三是备份。直接复制正在使用的库文件，属于给自己埋雷。
还有一个隐蔽坑：老项目长期不 sweep、不备份恢复，库文件越来越臃肿。火鸟的多版本并发控制需要清理旧版本，别把数据库当永动机。定期备份恢复或维护统计信息，是小系统也要做的卫生。
Q：工具生态会不会太冷门？
生态肯定不如 PostgreSQL、MySQL 热闹，这是事实。你搜索中文资料，会发现不少内容停在旧版本。好在核心工具够用：isql、gbak、gstat、gfix，加上 DBeaver，日常开发不缺胳膊少腿。
真正的问题是团队熟悉度。如果公司里没人碰过 Firebird，交接文档要写细：版本号、备份命令、库路径、字符集、驱动包、恢复步骤。少写一句，半年后排障就要多花一小时。
Q：这次测评结论是什么？
火鸟不是万能数据库，也不是过时玩具。它的价值在小而稳定的业务里很明显：安装轻、占用低、可以嵌入、事务能力比很多文件型方案扎实。
避坑的关键是别省基础动作。建库指定 UTF8，用服务版跑多人访问，用 gbak 备份，给索引和事务留心。做到这些，火鸟测评结果会比网上一句冷门数据库可靠得多。
常见问题
火鸟数据库还值得用吗？
在桌面软件、内网小系统、嵌入式场景仍值得考虑。大型互联网服务或强生态依赖项目，不建议优先选它。
火鸟和 SQLite 选哪个？
单机、极简、本地文件优先选 SQLite；多人访问、需要服务端事务和存储过程时，火鸟更合适。
火鸟测评最该看什么指标？
别只看跑分。要看备份恢复、并发访问、中文编码、工具链、团队接手成本，这些更接近真实项目。