node-red 不支持直接继承或嵌入现有节点（如 `debug` 或 `tcp in`）到自定义节点中；所有逻辑必须显式实现或通过消息流协作完成，而非内部“布线”。
在 Node-RED 开发中，一个常见误区是期望像面向对象编程那样“组合”或“嵌套”已有节点（例如将 debug 节点作为子组件集成进自定义节点内部）。但事实上，Node-RED 的运行时模型不提供节点级的封装或嵌入机制。RED.nodes.createNode() 并非用于实例化可运行的子节点，它仅用于在编辑器中创建节点配置对象，且该对象无法脱离上下文独立执行——更不会自动接入消息流、触发钩子或参与事件循环。
✅ 正确实践：通过消息流协同，而非节点内嵌
若你的机器人相机节点需同时采集图像、执行 AI 推理并输出调试信息，应设计为单一职责节点（如 camera-ai-processor），内部完整实现 TCP/HTTP 通信、图像解析、模型调用等逻辑；调试与日志则通过标准 node.log()、node.warn() 或发送额外消息（如 msg._debug = true）交由外部 debug 节点处理。用户工作流示例：
[camera-ai-processor] → [function: add timestamp] → [debug]
↘
[mqtt out]⚠️ 注意事项：
- ❌ 不要尝试 new RED.nodes.createNode('debug') —— 这会抛出错误或产生无行为的无效对象；
- ❌ 避免复制粘贴官方节点源码（如 debug.js），既违反许可风险，又导致维护困难；
- ✅ 推荐使用 node.status({fill:"green", shape:"dot", text:"ready"}) 和 node.send(msg) 标准接口保持兼容性；
- ✅ 若需复用逻辑（如 TCP 客户端），直接调用底层库（如 net、tls、axios），而非试图桥接节点实例。
? 总结：Node-RED 的扩展哲学是“松耦合、高内聚”——自定义节点应专注核心能力，周边功能（日志、监控、协议转换）交由标准节点链式协作。这不仅符合架构规范，也确保部署稳定性、调试可见性与未来升级兼容性。
