c3eb7125cc
详细说明: - 基于文旅订单班框架复制创建food-order-demo项目 - 修改端口配置为4174避免冲突 - 更新LandingPage为青莳轻食主题（绿色健康风格） - 重新定义7个食品行业专业Agent： * 市场研究专家：轻食市场分析、客群画像 * 营养配方师：营养成分配比、低卡高蛋白设计 * 供应链管理专家：有机食材供应、溯源体系 * 品牌策划师：品牌定位、店铺空间布局 * 财务分析师：投资预算、ROI分析 * 运营管理专家：运营流程、品控标准 * 食品创业导师：中央协调、方案整合 - 创建专用启动脚本start.sh - 验证系统可正常运行在端口4174 - 实现代码复用率90%，符合预期目标 影响文件: web_frontend/food-order-demo/ 技术栈: React 18 + TypeScript + Tailwind CSS + Zustand
signal-exit
When you want to fire an event no matter how a process exits:
- reaching the end of execution.
- explicitly having
process.exit(code)called. - having
process.kill(pid, sig)called. - receiving a fatal signal from outside the process
Use signal-exit.
// Hybrid module, either works
import { onExit } from 'signal-exit'
// or:
// const { onExit } = require('signal-exit')
onExit((code, signal) => {
console.log('process exited!', code, signal)
})
API
remove = onExit((code, signal) => {}, options)
The return value of the function is a function that will remove the handler.
Note that the function only fires for signals if the signal would cause the process to exit. That is, there are no other listeners, and it is a fatal signal.
If the global process object is not suitable for this purpose
(ie, it's unset, or doesn't have an emit method, etc.) then the
onExit function is a no-op that returns a no-op remove method.
Options
alwaysLast: Run this handler after any other signal or exit handlers. This causesprocess.emitto be monkeypatched.
Capturing Signal Exits
If the handler returns an exact boolean true, and the exit is a
due to signal, then the signal will be considered handled, and
will not trigger a synthetic process.kill(process.pid, signal) after firing the onExit handlers.
In this case, it your responsibility as the caller to exit with a
signal (for example, by calling process.kill()) if you wish to
preserve the same exit status that would otherwise have occurred.
If you do not, then the process will likely exit gracefully with
status 0 at some point, assuming that no other terminating signal
or other exit trigger occurs.
Prior to calling handlers, the onExit machinery is unloaded, so
any subsequent exits or signals will not be handled, even if the
signal is captured and the exit is thus prevented.
Note that numeric code exits may indicate that the process is already committed to exiting, for example due to a fatal exception or unhandled promise rejection, and so there is no way to prevent it safely.
Browser Fallback
The 'signal-exit/browser' module is the same fallback shim that
just doesn't do anything, but presents the same function
interface.
Patches welcome to add something that hooks onto
window.onbeforeunload or similar, but it might just not be a
thing that makes sense there.