Feature Flags & cfg
Usa features de Cargo y #[cfg(feature = ...)] para controlar logs de depuración, instrucciones solo para desarrollo y código específico del clúster en programas de Anchor.
Receta
[features]
default = []
debug-log = []
devnet-only = []#[cfg(feature = "debug-log")]
msg!("debug");Cuándo usar esto: Necesitas diferentes compilaciones para desarrollo vs mainnet o diagnósticos opcionales.
Ejemplo Funcional
#[cfg(feature = "devnet-only")]
#[program]
pub mod my_program {
pub fn airdrop_test_tokens(ctx: Context<Airdrop>) -> Result<()> {
// solo se compila cuando la feature está habilitada
Ok(())
}
}
#[cfg(not(feature = "devnet-only"))]
#[program]
pub mod my_program {
// instrucciones de producción solamente
}Lo que esto demuestra:
- Las features controlan la inclusión en tiempo de compilación
- Binario de mainnet más pequeño sin instrucciones de desarrollo
cfgen módulos requiere cuidado con#[program]- Documenta las features en README
Análisis Profundo
Advertencia de Anchor
Dividir módulos #[program] por cfg cambia el IDL entre compilaciones. Prefiere crates de desarrollo separados o instrucciones detrás de claves de administrador en lugar de enviar instrucciones de desarrollo a mainnet.
Patrón de feature de clúster
Usa constantes en Anchor.toml / scripts de compilación en lugar de múltiples módulos #[program] cuando sea posible.
Errores Comunes
- IDL diferente por conjunto de features - Confusión del cliente. Solución: Un perfil de lanzamiento para mainnet.
- Habilitar accidentalmente
devnet-onlyen mainnet - Superficie de ataque adicional. Solución: CI prohíbe la combinación de features. cfgen structs de cuenta - Desviación del diseño del IDL. Solución: Mantén el diseño de la cuenta estable entre compilaciones.- Feature de logs de depuración dejada activada - Desperdicio de CU. Solución: Features por defecto vacías.
- Error de dos módulos
#[program]- Errores de compilación. Solución: Un solo módulo de programa por compilación.
Alternativas
| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| Crate de programa de desarrollo separado | Separación clara | Flags de features en un solo crate |
| Puerta de administración en tiempo de ejecución | Mismo binario | Eliminación en tiempo de compilación |
Preguntas Frecuentes
¿Versión de Anchor?
0.32.1 en temas avanzados.
¿Cuándo usar zero_copy?
Diseños fijos grandes cuando Borsh CU es demasiado alto.
¿Es realloc reversible?
No fácilmente; planifica el crecimiento futuro.
¿Están las cuentas restantes en el IDL?
No; documentar por separado.
¿Qué necesita declare_program!?
JSON del IDL del llamador en tiempo de compilación.
¿Puede Anchor hacer CPI a Pinocchio?
Sí, con metadatos de cuenta correctos.
¿Flags de features y IDL?
Evita diferentes IDL por feature en mainnet.
¿Cómo medir CU?
LiteSVM, Surfpool, simulación en devnet.
¿Tipos de cuenta personalizados comunes?
No; último recurso.
¿Próximos pasos?
Ver enlaces relacionados para features.
Relacionado
- Logging & CU Cost - logs de depuración
- Program Upgrades - lanzamientos
- Making Programs Immutable - despliegue final
Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.