QBOX vs QBCore: FiveM Framework Comparison

Introduzione: perché i framework sono importanti

Il tuo framework determina la velocità con cui sviluppi le funzionalità, la stabilità della tua città e la facilità con cui puoi scalare. In FiveM, QBCore E QBOX Sono le due scelte moderne che la maggior parte dei proprietari valuta. Entrambe sono valide, ma ottimizzano per compromessi diversi: ampiezza dell'ecosistema vs. moderna architettura Ox-first. Questa guida spiega le differenze con indicazioni pratiche su cui puoi agire.

In breve

Nuovo server, stack moderno, ecosistema Ox fin dal primo giorno? Favore QBOX.
Città esistente con molte risorse e personale nativo di QB che conosce QBCore? Rimani acceso QBCore (o migrare in fasi).

Esplora i nostri contenuti di framework selezionati e le librerie di script:
• Script QBOX → https://fivemx.com/qbox-scripts/
• Script QBCore → https://fivemx.com/qbcore-scripts/
• Hub Framework → https://fivemx.com/frameworks

Definizioni (su una riga ciascuna)

QBCore: The most popular Lua RP framework for FiveM, with years of community scripts and tutorials. Nucleo repo: qbcore‑framework/qb‑core.
QBOX: Un percorso successore moderno con una filosofia Ox-first (ox_lib/oxmysql/ox_inventory), più un bridge di compatibilità QB per eseguire molte risorse QB con poche o nessuna modifica.

Problema che questo articolo risolve

Scegliere tra QBOX e QBCore senza dover rivoluzionare l'intero stack. Confronteremo funzionalità, modelli di prestazioni, realtà dell'ecosistema e forniremo checklist di migrazione in caso di passaggio.

Che cos'è QBCore?

Origini. QBCore è nato dalla comunità come un framework pragmatico e modulare per accelerare lo sviluppo di server RP. Ha definito convenzioni per giocatori, lavori, inventari, finanze, callback, esportazioni ed eventi comuni. Essendo presente da più tempo di QBOX, ha... il più grande catalogo di sceneggiature già pronte (gratuito e premium) e il maggior numero di tutorial su YouTube/Discord.

Punti di forza.

Scala dell'ecosistema. Migliaia di risorse con tag QB, da telefoni e lavori a strumenti di amministrazione e pacchetti di interfaccia utente. Più veloce nell'assemblare una città a partire da componenti esistenti.
Familiarità dello sviluppatore. Sviluppatori, staff e collaboratori della community spesso conoscono a memoria gli export e gli eventi di QBCore. La risoluzione dei problemi è rapida.
Convenzioni stabili. I dati dei cittadini, i callback, lo stato del server/giocatore e i modelli comuni sono ben compresi, riducendo l'attrito durante l'onboarding.
Livello DB flessibile. La maggior parte dei server QBCore moderni eseguono oxmysql Oggi; gli stack più vecchi utilizzavano ghmattimysql/mysql-async. È possibile mantenere il database e gli script modernizzandoli.

Punti deboli.

Varianza ereditaria. Molti script QB "classici" sono precedenti alle best practice di Ox: qualità del codice mista e maggiore refactoring quando si spinge per 0,00-0,01 ms di inattività.
Frammentazione dell'interfaccia utente. La dipendenza storica da vecchie interfacce utente/inventari significa che spesso si sostituisce o si adatta a inventario_di_bue e comunque i kit UI più recenti.
Futuro servizio di pulizia. Man mano che le best practice si spostano verso le utilità Ox/tipizzate, si procederà gradualmente al refactoring del codice di collegamento o all'aggiunta di adattatori.

Esplora la nostra libreria di contenuti QB: Script QBCore → https://fivemx.com/qbcore-scripts/
Come fare: Personalizza gli script QBCore → https://fivemx.com/how-to-customize-qbcore-scripts

Sito web QBCore

Che cosa è QBOX?

Posizionamento. QBOX abbraccia il Ecosistema dei buoi pronto all'uso: ox_lib, oxmysqle un approccio moderno alle esportazioni, agli eventi e ai moduli. Viene fornito con un strato di ponte che conserva compatibilità con la maggior parte delle risorse QB, consentendoti di adottare un core più pulito senza rinunciare ai tuoi script preferiti.

Caratteristiche principali.

Fondamento del bue primogenito. Utilità coerenti (matematica/tabelle/stringhe/disegno) e modelli moderni promuovono risorse più pulite e veloci.
Ponte di compatibilità. Molti script QB vengono eseguiti con modifiche minime o nulle, il che è utile per le migrazioni graduali.
Batterie incluse. I moduli multipersonaggio, multi-lavoro/gruppo, coda e altri elementi indispensabili sono moduli di prima classe, non componenti aggiuntivi ad hoc.

Professionisti

Impostazioni predefinite orientate alle prestazioni. I modelli basati su Ox aiutano a ridurre i cicli di sondaggio e le chiamate di estrazione, a patto che si rispettino le migliori pratiche tra le risorse.
Posizione di sicurezza e qualità. Indicazioni chiare per evitare modifiche al core; configurazione anziché patch. Audit più semplici.
A prova di futuro. Sviluppato per FiveM 2025+: Lua 5.4, oxmysql e stack UI moderni.

Contro

Ecosistema più piccolo (per ora). Ti appoggerai al bridge di compatibilità o agli script di porta che si basano sui QB-ismi.
Curva di apprendimento del team. Il personale abituato agli eventi/esportazioni QBCore dovrà adattarsi agli idiomi Ox/Qbox.

Hub QBOX → https://fivemx.com/qbox-ox-stack
Script QBOX (curati) → https://fivemx.com/qbox-scripts/

Sito web QBOX

QBOX vs QBCore — Confronto diretto (matrice delle funzionalità)

Tabella riassuntiva

Zona	QBOX	QBCore	Verdetto pratico
Modelli di prestazione	Ox-first, moduli snelli, meno footgun legacy. È più facile mantenere la CPU inattiva a 0,00-0,02 ms quando si seguono le pratiche Ox.	Varia in base all'annata della risorsa; molti ottimi script moderni, alcuni più vecchi ricchi di cicli di tick.	Per una nuova città che punta a un inattività estremamente bassa, QBOX ha il vantaggio di avere uno stack QBCore ben curato che può eguagliarlo.
Ecosistema e script	Catalogo nativo più piccolo; si basa sul bridge compatibile QB + risorse Ox.	Il più ampio catalogo di script e tutorial già pronti.	Se hai bisogno di velocità nei contenuti, oggi QBCore è la scelta giusta.
Livello di database	oxmysql per impostazione predefinita; schema e query in genere in stile Ox.	Anche i server moderni utilizzano oxmysql; gli stack legacy potrebbero essere mysql‑async/ghmatti.	Collegati al 2025 se utilizzi già oxmysql; la migrazione è necessaria solo se utilizzi ancora mysql-async.
Inventario/interfaccia utente	Allineato al bue (comunemente inventario_di_bue). Interfacce utente pulite ed estensibili.	Storicamente qb-inventory e molti fork; molti amministratori standardizzano su inventario_di_bue Comunque.	Se preferisci le convenzioni dell'interfaccia utente Ox, QBOX è la soluzione migliore.
Dipendenze/strumenti	ox_lib, oxmysql, moduli integrati; esportazioni/eventi coerenti.	qb-core più molte risorse qb-; la qualità varia.	QBOX è più opinabile; QBCore è più aperto.
Personalizzazione/DX	Moduli basati sulla configurazione, separazione netta; spingono gli sviluppatori verso API basate sull'esportazione.	Esportazioni/eventi noti; tonnellate di esempi di codice online.	QBCore è più semplice per i team con esperienza QB; QBOX è più adatto per gli sviluppatori principianti/Ox.
Comunità e documentazione	Documentazione più ridotta ma mirata e responsabili attivi.	Ampia comunità, numerose guide non ufficiali.	Hai bisogno di risposte rapide? QBCore ha più contenuti per la community; la documentazione di QBOX sta migliorando.
A prova di futuro	Costruito attorno alle migliori pratiche attuali (Lua 5.4, stack Ox, utilità tipizzate).	In continua evoluzione: molti server vengono modernizzati pezzo per pezzo.	Leggero vantaggio QBOX per una pulizia a lungo termine; QBCore rimane valido.
Posizione di sicurezza	Incoraggia le modifiche senza nucleo, l'isolamento dei moduli e flussi di autorizzazione più puliti.	Dipende da risorse specifiche; molte sono solide, altre più vecchie un po' meno.	Le impostazioni predefinite di QBOX riducono le modifiche soggette a incidenti; con QBCore, applica revisioni e linting.
ricette txAdmin	Sono disponibili istruzioni e ricette ufficiali; avvio rapido.	Ricette e modelli collaudati ovunque.	Pareggio; scegli la ricetta più vicina alla tua pila.
Attrito migratorio	Il ponte QB riduce l'attrito; l'allineamento Ox riduce al minimo i futuri refactoring.	Minimo se si rimane nel territorio dei QB; migrare in seguito richiede impegno.	Se prevedi Ox ovunque, avvia QBOX.
Curva di apprendimento	Nuovo se la tua squadra conosce solo le abitudini del QB; Ox da adottare.	Più basso per gli amministratori esistenti; la maggior parte dello staff conosce già i flussi QB.	Scegli in base alle competenze attuali del tuo personale.

Note che contano nella pratica

La tua risorsa peggiore determina le prestazioni. La scelta del framework aiuta, ma i problemi più gravi sono l'interfaccia utente, le risorse di streaming e i loop mal sincronizzati. Profila sempre con resmon e sorvegliare ogni PR.
L'allineamento del bue è la tendenza. Che tu utilizzi QBOX o QBCore, passare a oxmysql, ox_lib, E inventario_di_bue tende a migliorare l'affidabilità e l'esperienza degli sviluppatori.

Quando scegliere QBOX

Scegliere QBOX se la maggior parte di queste sono vere:

Stai lanciando un nuovo server e non hai bisogno di decine di script legacy riservati solo al QB fin dal primo giorno.
Tu vuoi Bue ovunque: ox_lib, oxmysql, ox_inventory, ox_target.
Ti interessa manutenibilità a lungo termine più del numero massimo di script del primo giorno.
Il tuo team è a suo agio nell'adottare nuovi modelli e nel leggere i documenti ufficiali.

Vantaggi operativi:

Un approccio più pulito basato sulla configurazione e sulle patch riduce il rischio di "modifiche al core".
Meno strati di colla per ottenere un'interfaccia utente/esperienza utente moderna.
È più facile standardizzare le pratiche di codifica tra i collaboratori.

Iniziare: Hub QBOX → https://fivemx.com/qbox-ox-stack • Script → https://fivemx.com/qbox-scripts/

Quando scegliere QBCore

Scegliere QBCore se la maggior parte sono vere:

Hai già eseguito un Città QB con giocatori e staff formati in tempo reale sui flussi del QB.
Hai bisogno massima copertura dell'ecosistema oggi (telefoni, lavori, interfacce utente, CAD, pacchetti di amministrazione) con un porting minimo.
Hai intenzione di modernizzare sul posto: adottare oxmysql, sostituire vecchi inventari/interfacce utente, riorganizzare i cicli pesanti e rafforzare i permessi.

Vantaggi operativi:

Assunzioni e onboarding più rapidi: la maggior parte dei candidati conosce gli eventi/esportazioni dei QB.
Utilizzando le risorse e le guide esistenti, il tempo necessario per la pubblicazione è breve.

Guide interne utili:

Catalogo degli script QBCore → https://fivemx.com/qbcore-scripts/
Come fare: Personalizza gli script QBCore → https://fivemx.com/how-to-customize-qbcore-scripts

Migrazione: QBCore → QBOX (in modo sicuro, a fasi)

Puoi passare a QBOX senza danneggiare il tuo server se lo consideri come una migrazione di prodotto: audit → adattamento → doppia esecuzione → passaggio.

1) Audit pre-migrazione

Inventario e interfaccia utente: Elenca tutto ciò che è legato a qb-inventory/vecchie interfacce utente. Decidi se adottare inventario_di_bue (consigliato) e un kit di interfaccia utente coerente.
Banca dati: Conferma di essere attivo oxmysqlIn caso contrario, eseguire prima la migrazione: MySQL‑Async → oxmysql guida → https://fivemx.com/mysql-async-to-oxmysql
Identificatori: Standardizza il tuo modello di identificazione (Steam, licenza, citizenID, Discord). Definisci come viene archiviato e referenziato. Vedi: Migrazione degli identificatori SQL → https://fivemx.com/sql-identifiers-migration
Script da trasferire: Tagga le risorse in base allo sforzo: compatibile così com'è, necessita di un piccolo adattatore, riscrivere/sostituireTieni un foglio di calcolo attivo.

2) Costruisci adattatori dove conviene

Utilizzo modelli di adattatore per esporre le stesse esportazioni/eventi che i tuoi script esistenti si aspettano, mentre chiamano internamente i moduli QBOX o le utilità Ox. Riferimento: Conversione degli script FiveM → https://fivemx.com/converting-fivem-scripts E Modelli di adattatore → https://fivemx.com/adapter-patterns
Dove possibile, preferire sostituzioni di Ox drop-in (ad esempio, le funzionalità di ox_inventory) rispetto allo shimming delle vecchie API.

3) Strategia di migrazione dei dati

Giocatori e personaggi: Scrivere codice SQL idempotente per mappare/rinominare le colonne e assicurarsi che chiavi/indici esistano per i moduli QBOX. Mantenere uno script di rollback.
Articoli/negozi/veicoli: Normalizza le tabelle in base ai tuoi nuovi sistemi di inventario/garage. Testa i flussi di acquisto, deposito, deposito, vano portaoggetti, bagagliaio e prove.
Permessi: Ricreare i ruoli del personale e delle mansioni utilizzando le nuove esportazioni/eventi; verificare i gate di comando e gli strumenti di amministrazione.

4) Doppia esecuzione e verifica

Esegui un città di messa in scena con snapshot DB speculari e set di risorse simili a quelli di produzione.
Convalidare resmon in condizioni di inattività e sotto carico (punti critici dei lavori, picchi, report). Definire limiti massimi di budget per risorsa e correggere i valori anomali prima del cutover.
Test del fumo: onboarding, multipersonaggio, alloggi, veicoli, telefono, fatturazione, artigianato, polizia, servizi di emergenza medica, prove, rapine.

5) Taglio e indurimento

Annunciare una finestra di manutenzione; migrare i dati; cambiare le ricette; effettuare il re-seed delle cache.
Monitorare attentamente i log (txAdmin, console del server, Ox logger). Aggiungere avvisi di runtime per i picchi di errore.
Pianifica un finestra di hotfix con i tuoi sviluppatori online.

Liste di controllo e guide per la migrazione

Conversione degli script FiveM → https://fivemx.com/converting-fivem-scripts
MySQL‑Async a oxmysql → https://fivemx.com/mysql-async-to-oxmysql
Migrazione degli identificatori SQL → https://fivemx.com/sql-identifiers-migration
Hub di conversione del framework → https://fivemx.com/framework-conversion

Raccomandazioni per il 2025

Se stai iniziando da zero: scegliere QBOX per allinearti alle best practice di Ox fin dal primo giorno. Scriverai risorse più pulite, ridurrai al minimo il debito tecnologico legacy e continuerai a eseguire molti script creati dal QB tramite il bridge.

Se gestisci una città QB matura: rimanere acceso QBCore e modernizza sul posto: oxmysql, ox_inventory, budget di revisione aggressivi e standard di revisione del codice. Pianifica un Pilota QBOX nella messa in scena per quantificare i benefici prima di qualsiasi passaggio.

Se sei indeciso: Prototipa entrambi con pacchetti di contenuti identici e misura: tempo di implementazione, risoluzione in condizioni di inattività/sotto carico e soddisfazione del personale. Scegli quello che riduce i costi di modifica continua.

Conclusione e prossimi passi

Entrambi i framework possono gestire una città di alto livello. La differenza sta nel livello di eredità che si desidera portare con sé e nel livello di standardizzazione che si desidera per il futuro.

Prossimi passi:

Esplorare Script QBOX → https://fivemx.com/qbox-scripts/
Esplorare Script QBCore → https://fivemx.com/qbcore-scripts/
Leggi di più su Conversione del framework → https://fivemx.com/framework-conversion

Riferimenti esterni (scopri di più)

QBOX GitHub (qbx_core) → https://github.com/Qbox-project/qbx_core
QBCore GitHub (qb-core) → https://github.com/qbcore-framework/qb-core
FiveM Docs — Manifesto delle risorse (fxmanifest.lua) → https://docs.fivem.net/docs/scripting-reference/resource-manifest/resource-manifest/

Utilizza queste sezioni FiveMX per confrontare prodotti correlati, categorie e indicazioni sull'impostazione prima di scegliere una risorsa.