Для чего нужен тип Symbol в JavaScript?

Что проверяют

Знаете ли вы, что Symbol это примитив для уникальных ключей и протоколов языка, а не способ спрятать данные. Следом обычно спрашивают про Symbol.for, про well-known символы и про то, видны ли символьные ключи в JSON.stringify.

Как отвечать

Symbol появился в ES2015, typeof для него возвращает 'symbol'. Главное:

• уникальность: Symbol('id') !== Symbol('id'), описание нужно для отладки и доступно через .description. Конструктора нет, new Symbol() бросает TypeError;
• ключи без конфликтов: библиотека может добавить в чужой объект свойство, которое не пересечётся со строковыми ключами пользователя;
• невидимость для обычного перебора: символьные ключи пропускают for...in, Object.keys и JSON.stringify, но их отдают Object.getOwnPropertySymbols и Reflect.ownKeys. Это защита от случайных коллизий, а не приватность;
• глобальный реестр: Symbol.for('app.key') возвращает один и тот же символ по строке во всём процессе, даже между контекстами vm, а Symbol.keyFor делает обратное. В Node это спасает, когда в node_modules оказались две копии одной библиотеки и обычные символы у них разные;
• well-known символы: Symbol.iterator делает объект перебираемым в for...of, Symbol.asyncIterator работает в for await, так и читают потоки: for await (const chunk of readable). Ещё есть Symbol.toPrimitive, Symbol.toStringTag, Symbol.hasInstance.

Пример из Node: util.inspect.custom это Symbol.for('nodejs.util.inspect.custom'). Метод под этим ключом задаёт, как объект выглядит в console.log, и не мешает сериализации.

Где спотыкаются

Называют символьные свойства приватными. Любой код достанет их через Reflect.ownKeys. Для настоящей приватности нужны поля #field или замыкание.

Удивляются, что символьные ключи пропали после JSON.stringify и не доехали в ответе API.

Склеивают символ со строкой: ` id: ${sym} бросает TypeError, нужно явное String(sym) или sym.description`.