Spring Boot YAML vs Properties: Порівняння Конфігурації та Питання для Співбесіди 2026

Spring Boot підтримує два формати конфігурації: YAML (application.yml) та Properties (application.properties). Обидва досягають однієї мети, проте відрізняються синтаксисом, зручністю читання та застосуванням у конкретних сценаріях. Це порівняння розглядає практичні відмінності та охоплює питання, що виникають на співбесідах щодо зовнішньої конфігурації Spring Boot.

Spring Boot Properties vs YAML: Відмінності Коротко

У Spring Boot 4.1, поточній лінійці релізів, обидва формати наповнюють той самий Environment і зв'язуються однаково. Відмінності стосуються синтаксису, кількох правил завантаження та того, що відбувається, коли існують обидва файли.

Кандидати найчастіше пропускають рядки про @PropertySource та про два файли в одному розташуванні. Довідник Spring Boot щодо зовнішньої конфігурації зазначає, що файли YAML не можна завантажити через @PropertySource або @TestPropertySource, а коли application.properties і application.yml лежать поруч, перемагає значення з .properties. Офіційна рекомендація: обрати один формат для всього застосунку.

Порівняння Синтаксису YAML та Properties

Найбільш помітна відмінність полягає у способі представлення ієрархічних даних. Файли Properties використовують крапкову нотацію в кожному рядку, тоді як YAML застосовує відступи для вираження вкладеності.

# application.properties
server.port=8080
server.servlet.context-path=/api
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=admin
spring.datasource.password=${DB_PASSWORD}
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=false

Еквівалентна конфігурація YAML візуально групує пов'язані налаштування:

# application.yml
server:
  port: 8080
  servlet:
    context-path: /api

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/mydb
    username: admin
    password: ${DB_PASSWORD}
  jpa:
    hibernate:
      ddl-auto: validate
    show-sql: false

YAML зменшує повторення, коли кілька властивостей мають спільний префікс. У файлі properties spring.datasource з'являється тричі, тоді як YAML оголошує його лише один раз.

Керування Профілями в Конфігурації Spring Boot

Профілі Spring Boot дозволяють мати різні конфігурації для середовищ розробки, staging та production. Обидва формати підтримують файли для окремих профілів і багатодокументні файли.

Класичний підхід передбачає один файл на профіль:

# application-dev.properties
server.port=8080
spring.datasource.url=jdbc:h2:mem:devdb
logging.level.root=DEBUG

# application-prod.properties
server.port=80
spring.datasource.url=jdbc:postgresql://prod-server:5432/proddb
logging.level.root=WARN

YAML підтримує синтаксис кількох документів в одному файлі за допомогою роздільника ---:

# application.yml
spring:
  profiles:
    active: dev

---
spring:
  config:
    activate:
      on-profile: dev
server:
  port: 8080
logging:
  level:
    root: DEBUG

---
spring:
  config:
    activate:
      on-profile: prod
server:
  port: 80
logging:
  level:
    root: WARN

Файли properties підтримують таку саму багатодокументну структуру. Рядок, що містить лише #--- (або !---), розділяє файл на документи:

# application.properties
spring.profiles.active=dev
#---
spring.config.activate.on-profile=dev
server.port=8080
logging.level.root=DEBUG
#---
spring.config.activate.on-profile=prod
server.port=80
logging.level.root=WARN

Перед роздільником не повинно бути пробілів, і він має складатися рівно з трьох дефісів. Починаючи з Spring Boot 2.4, властивість spring.config.activate.on-profile замінила старіший синтаксис spring.profiles в обох форматах.

Активацію профілів, групи профілів і біни з @Profile можна відпрацювати в модулі співбесіди про профілі та середовища.

Списки та Складні Структури Даних

YAML чудово справляється з представленням списків та вкладених структур. Це важливо для конфігурацій правил безпеки, CORS-мапінгів або користувацьких бінів.

# application.yml
app:
  security:
    allowed-origins:
      - https://sharpskill.dev
      - https://api.sharpskill.dev
    cors:
      allowed-methods:
        - GET
        - POST
        - PUT
        - DELETE
    jwt:
      secret: ${JWT_SECRET}
      expiration-ms: 86400000

Еквівалент у properties вимагає індексної нотації:

# application.properties
app.security.allowed-origins[0]=https://sharpskill.dev
app.security.allowed-origins[1]=https://api.sharpskill.dev
app.security.cors.allowed-methods[0]=GET
app.security.cors.allowed-methods[1]=POST
app.security.cors.allowed-methods[2]=PUT
app.security.cors.allowed-methods[3]=DELETE
app.security.jwt.secret=${JWT_SECRET}
app.security.jwt.expiration-ms=86400000

Додавання нового origin у файл YAML означає дописування рядка. У properties кожен існуючий індекс повинен залишатися правильним, а новий запис потребує наступного номера індексу.

Типобезпечна Конфігурація з @ConfigurationProperties

Spring Boot зв'язує значення конфігурації з Java-класами через @ConfigurationProperties. Обидва формати працюють ідентично з цією анотацією.

import org.springframework.boot.context.properties.ConfigurationProperties;
import java.util.List;

@ConfigurationProperties(prefix = "app.security")
public record AppSecurityProperties(
    List<String> allowedOrigins,
    CorsConfig cors,
    JwtConfig jwt
) {
    public record CorsConfig(List<String> allowedMethods) {}
    public record JwtConfig(String secret, long expirationMs) {}
}

Гнучке зв'язування Spring Boot автоматично конвертує між різними угодами найменування. Властивість app.security.allowed-origins зв'язується з allowedOrigins незалежно від того, чи джерелом є YAML чи properties.

import org.springframework.context.annotation.Configuration;
import org.springframework.boot.context.properties.EnableConfigurationProperties;

@Configuration
@EnableConfigurationProperties(AppSecurityProperties.class)
public class SecurityConfig {
    
    private final AppSecurityProperties securityProperties;
    
    public SecurityConfig(AppSecurityProperties securityProperties) {
        this.securityProperties = securityProperties;
    }
    
    // CORS configuration using securityProperties.cors().allowedMethods()
}

Більше інформації про патерни конфігурації Spring Security можна знайти в модулі основ Spring Security.

Поширені Питання на Співбесіді про Конфігурацію Spring Boot

Конфігурація є частою темою на співбесідах зі Spring Boot. Інтерв'юери оцінюють розуміння зовнішньої конфігурації, налаштувань для конкретних середовищ та зв'язування властивостей.

Питання: Який порядок пріоритетів джерел конфігурації?

Spring Boot завантажує конфігурацію з кількох джерел у певному порядку. Джерела з вищим пріоритетом перевизначають нижчі (це спрощена версія офіційного списку, який також охоплює JNDI, параметри сервлетів і тестові анотації):

1. Аргументи командного рядка (--server.port=9000)
2. SPRING_APPLICATION_JSON (вбудований JSON у змінній середовища або системній властивості)
3. Системні властивості Java (-Dserver.port=9000)
4. Змінні середовища операційної системи (SERVER_PORT=9000)
5. Файли config data (application.yml, application.properties та їхні варіанти для профілів)
6. Анотації @PropertySource
7. Властивості за замовчуванням через SpringApplication.setDefaultProperties

Усередині кроку 5 діє другий порядок: файли для конкретного профілю перевизначають загальні, а файли поза упакованим jar перевизначають файли всередині нього. У межах одного розташування .properties перевизначає .yml. Кандидат, який може пояснити, чому значення з application.yml мовчки ігнорується (поруч залишився забутий application.properties), демонструє реальний досвід налагодження.

Питання: Коли обирати properties замість YAML?

Файли properties мають переваги в певних ситуаціях:

• Завантаження через @PropertySource: YAML так завантажити не можна, тому додаткові файли, що імпортуються цією анотацією, мають бути у форматі .properties
• Знайомство команди: Синтаксис properties простіший для розробників, нових у Spring Boot
• Однорядкові значення: Плоскі конфігурації без вкладеності нічого не виграють від YAML
• Жодних помилок відступів: зайвий пробіл у YAML мовчки переносить ключ під неправильний батьківський вузол

YAML працює краще, коли:

• Конфігурація має глибоку вкладеність (три або більше рівнів)
• Списки вимагають частих модифікацій
• Зручність читання важлива для складних конфігурацій

Питання: Як обробляти чутливі значення конфігурації?

Ніколи не слід комітити секрети до системи контролю версій. Spring Boot надає кілька підходів:

# application.yml - reference environment variable
spring:
  datasource:
    password: ${DB_PASSWORD}

Для production-систем Spring Cloud Config Server або HashiCorp Vault забезпечують централізоване керування секретами. Посібник з моніторингу Actuator охоплює захист чутливих ендпоінтів.

Питання: Що таке Jasypt і як він шифрує властивості Spring Boot?

Jasypt Spring Boot розшифровує значення, обгорнуті в ENC(...), під час побудови Environment, тож зашифровані секрети можуть зберігатися в application.yml або application.properties і зв'язуватися як звичайні значення:

# application.properties
spring.datasource.password=ENC(nrmZtkF7T0kjG/VodDvBw93Ct8EgjCA+)

# The master password is supplied at runtime, never committed
java -Djasypt.encryptor.password=$JASYPT_MASTER_KEY -jar app.jar

jasypt.encryptor.password є єдиною обов'язковою властивістю, а алгоритм за замовчуванням PBEWITHHMACSHA512ANDAES_256. Формат не має значення: те саме значення ENC(...) працює і в YAML, і в properties.

Відповідь, яка вирізняє senior-кандидата: Jasypt не прибирає секрет, а лише переміщує його. Будь-хто з майстер-паролем може розшифрувати кожне значення в репозиторії, а зміна цього пароля означає повторне шифрування всіх значень. Vault або хмарний менеджер секретів додають контроль доступу, аудит і ротацію, яких Jasypt не забезпечує.

Валідація @ConfigurationProperties під Час Запуску

Spring Boot валідує класи @ConfigurationProperties під час запуску в поєднанні з анотаціями Jakarta Bean Validation.

import jakarta.validation.constraints.NotBlank;
import jakarta.validation.constraints.Positive;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.validation.annotation.Validated;

@Validated
@ConfigurationProperties(prefix = "app.database")
public record DatabaseProperties(
    @NotBlank String url,
    @NotBlank String username,
    @Positive int poolSize
) {}

Якщо app.database.pool-size відсутній або від'ємний, застосунок швидко завершує роботу під час запуску з чітким повідомленням про помилку. Ця валідація працює ідентично для джерел YAML та properties.

Файли Конфігурації для Конкретних Середовищ

Spring Boot підтримує додаткові розташування файлів конфігурації поза стандартним src/main/resources. Властивість spring.config.import завантажує зовнішні файли:

# application.yml
spring:
  config:
    import:
      - optional:file:./config/
      - optional:configserver:http://config-server:8888

Префікс optional: запобігає помилці запуску, коли файл не існує. Цей патерн дозволяє локальну розробку з типовими значеннями, тоді як production отримує конфігурацію з центрального сервера. Більше практичних питань про ці файли є в модулі співбесіди про application.properties та YAML.

Джерела

• Довідник Spring Boot: Externalized Configuration: порядок джерел властивостей, багатодокументні файли properties з #---, пріоритет .properties над YAML, відсутність підтримки YAML у @PropertySource
• Релізи Spring Boot: 4.1.2 є поточним GA-релізом (жовтень 2026)
• README Jasypt Spring Boot: синтаксис ENC(...), алгоритм за замовчуванням, вимога Spring Boot 3.5+

Ключові Висновки щодо Конфігурації Spring Boot

• YAML зменшує повторення для конфігурацій зі спільними префіксами та обробляє списки чистіше
• Файли properties добре працюють для плоских конфігурацій та команд, менш знайомих із синтаксисом YAML
• Spring Boot 4.1 однаково ставиться до обох форматів для зв'язування та валідації @ConfigurationProperties
• Обидва формати підтримують кілька профілів в одному файлі: --- у YAML, #--- у properties
• Коли обидва файли лежать в одному розташуванні, перемагає .properties, і лише файли properties можна завантажити через @PropertySource
• Пріоритет конфігурації слідує визначеному порядку: аргументи командного рядка перевизначають змінні середовища, які перевизначають файлову конфігурацію
• Чутливі значення мають бути у змінних середовища або системах керування секретами; значення Jasypt ENC(...) лише переносять секрет на майстер-пароль
• Використання spring.config.import дозволяє завантажувати конфігурацію із зовнішніх джерел у production-середовищах