下信息僅為科普，不應(yīng)視為診療建議，不能取代醫(yī)生對特定患者的個體化判斷。
前兩天有一位V+會員在專屬會員群里問我：通過什么方法可以更好地補充營養(yǎng)？
這位會員患有鼻咽癌，平時吃飯吞咽困難，喂一頓飯要兩個小時還老是嗆咳，吃的很少體重也過輕，經(jīng)常有渾身酸痛、低燒、惡心、吃不下飯的情況。
我提醒他首先別忘了去當(dāng)?shù)蒯t(yī)院營養(yǎng)科就診，另外要重視日常家庭營養(yǎng)支持，比如自己做飯、購買商品制劑以外，還可以考慮勻漿膳。
本文1300字，寫作用時3小時，閱讀大約需要 4 分鐘
一. 勻漿膳是什么
二. 有什么優(yōu)點？適合哪些人群？
三. 有什么缺點
四. 怎么做？
五. 注意什么？
六.瘦點不好嗎？
勻漿膳顧名思義本質(zhì)上是膳食，只是經(jīng)過了加工，打成了勻漿的狀態(tài)。相比于湯水，其中的熱量會高很多。
除了最經(jīng)典常見的全營養(yǎng)粉，勻漿膳也是價格比較低廉和實用的方案。
勻漿膳整體營養(yǎng)比較均衡，吸收速度比普通食物快，來源多樣，配方靈活，耐受性也會比較好，滲透壓不會太高，不容易出現(xiàn)腹瀉。
因為都是天然食物，口味上的調(diào)整相對方便，對胃腸道的刺激會比較小。
而且勻漿膳也可以通過鼻胃管、鼻十二指腸、鼻空腸管等方式來輸注。
對于機能退化，消化功能不健全、進食困難的人群來說，還是很實用的。
如果確定了勻漿膳適合自己的情況，可以考慮自己或家人來置備。
最基礎(chǔ)的配方：將豬肉煮熟后加入油菜等青菜，配上牛奶、水和米飯后攪拌成漿，配方可以參考均衡飲食的模式，蛋白質(zhì)來源可以是雞蛋、雞胸脯肉、豬瘦肉、豬肝、豆制品等等。
一定要注意別忘了放鹽和食用油。
復(fù)雜的配方可以考慮用豆?jié){或其他更多種的主食、蔬菜。還可以加些維生素片劑在里邊。
比如：脫脂牛奶600ml，饅頭200g，白砂糖50g，油菜100g，胡蘿卜100g，雞胸脯肉50g，雞蛋1個，植物油10ml，鹽2克，復(fù)合型維生素礦物質(zhì)一片，維生素C 100mg。
如果已有置管，喂養(yǎng)前要注意一下管是否通暢，可以先用20-30毫升的溫開水沖洗一下。
一開始建議先給100到200毫升，每天三四次，以后可以逐漸過渡到每次300到400毫升，每天五六次。要小心不要一次給的量太多，以免引起反流或者腹脹！
除了家庭自制勻漿膳以外，別忘了考慮商品制劑，營養(yǎng)成分上可以更加明確，特別是大大的減少占用的時間和精力，也更為衛(wèi)生。在淘寶上就可以買到，具體可以參考一下產(chǎn)品的說明書，最好在醫(yī)院營養(yǎng)師的指導(dǎo)下使用。
有人可能會說，需要這么注意營養(yǎng)嗎？不是說“千金難買老來瘦”嘛？
這是一種錯誤的觀點，老年人肌肉衰減、消瘦是很危險的。
其實不僅老年人，每一位過瘦的朋友都應(yīng)該好好計劃一下怎樣保證營養(yǎng)，合理增重。
作者：顧中一，北京營養(yǎng)師協(xié)會理事，清華大學(xué)公共衛(wèi)生碩士。微博2018十大影響力健康醫(yī)療大V，人民日報2017年十大科學(xué)傳播人物，八年三甲醫(yī)院營養(yǎng)師經(jīng)驗，所著科普圖書已銷售十余萬冊。
參考資料：
1.吳雅芳, 徐建萍, 張兵, et al. 老年病人長期應(yīng)用自制勻漿膳進行腸內(nèi)營養(yǎng)支持的臨床研究[J]. 護理研究, 2005, 19(27):2516-2517.
2.胡麗娟, 盧靜霞, 沈瓊, et al. 家庭經(jīng)腸營養(yǎng)病人的健康教育[J]. 護士進修雜志, 2001, 16(4):308-309.
3.周策, 王梓凌, 趙雪平, et al. 長期鼻飼勻漿膳食的老年患者鼻飼模式的研究[J]. 中華護理雜志, 2007, 42(10).
4.徐蕊, 譚慧莉. 鼻飼勻漿食物患者食物返流的預(yù)見性護理研究[J]. 國際護理學(xué)雜志, 2007, 26(11):1141-1143.
5.https://mp.weixin.qq.com/s?src=11×tamp=1550393771&ver=1433&signature=T31bTsxPPjqj48M8apGRA9l2oIL10jf7Q-x1QzKmTyjsErWCO9tlZip7mCwI6NHaOP8DxBFFm*z*TK*nwgO6k2Z08Hy9qNcybJsHpdFKsbumc8rn0r0Lmd3IghiwPzQt&new=1
6.https://mp.weixin.qq.com/s?src=11×tamp=1550393771&ver=1433&signature=2aUDohyMwTY1dleWTrrW52QebKjQQUzNoOf5ZotWgULN*iVMz7HQNYRAJncb-p9kILIgGubUNEvI-GGpBJfHSC0jllIwtQloR3kJX5GlXAbg2AJljqb5SX9wtoN33bTt&new=1
7.https://mp.weixin.qq.com/s?src=3×tamp=1550393771&ver=1&signature=F1Yz6I*-HTx6B1VNWzoqMRMZYkOOioKsDroRQ*Y32pv2eE5D64CvmWVXHzu0Xe6fSxoXUZaQpC1UR4I9mwFwikgYH0JbzUSkEdbEyXYDG3RlnUDajaxhomJFihIGJ3X76J2DdJNNCNLUbw7mTOxzoQ==
8.https://mp.weixin.qq.com/s?src=11×tamp=1550393771&ver=1433&signature=0ummbWcsMd*3dPgbb35b5QZ2WuY8DekDfDRP6gNjnE9dFbD3RcWuNXPfEB*TFSY7GeVIBthpYAjQg-9YlGsnyWysnpxKTb5Y6ccpWfGUIqrV0oWyY-xMkCurYTYhVd6P&new=1
9.https://mp.weixin.qq.com/s?src=3×tamp=1550393771&ver=1&signature=wWyiTWGsFVesn8xPgqICvNFtf0MNaa-sa8tPif3C42oyPAX-Lxpd9nOMy7V*QPSg8AVdLlSrP9cWVUAwuc4N3VUD4pnvuK4yNEBz50BxfQARKPnADGRheTgNzLhmw50X9HLx3JROVehSi0NNL55C-pzaC7O*2-nfCETNkqC9mqA=
上一篇我們聊到了 Console 為什么會卡死，讀過那篇文章的朋友相信對 conhost.exe 有了一個大概的了解，這一篇更進一步聊一聊窗口的特殊事件 Ctrl+C 底層流轉(zhuǎn)到底是什么樣的，為了方便講述，讓 chagtgpt 給我生成一段Ctrl+C 的業(yè)務(wù)代碼。
class Program
{
static void Main(string[] args)
{
Console.CancelKeyPress +=new ConsoleCancelEventHandler(CancelKeyPressHandler);
Console.WriteLine("按下 Ctrl+C 試試看！");
while (true)
{
// 這里寫你的代碼
}
}
static void CancelKeyPressHandler(object sender, ConsoleCancelEventArgs e)
{
Console.WriteLine("你按下了 Ctrl+C！");
// 在這里可以添加你希望執(zhí)行的代碼
e.Cancel=true;
}
}
然后簡單跑一下，確認代碼沒毛病。
相信很多朋友看了這段代碼知道這是一種發(fā)布訂閱模式，代碼訂閱了 Console.CancelKeyPress 事件，一旦有 Ctrl+C 或者 Ctrl+Break 發(fā)生就會自動執(zhí)行對應(yīng)的訂閱邏輯，但這里有一個問題，Ctrl+C 是一種窗口事件，所以必然會有 Win32 API 的參與，有了這個思路就可以反編譯看下 Console.CancelKeyPress 底層到底用沒用到 Win32 API ，參考代碼如下：
private unsafe static PosixSignalRegistration Register(PosixSignal signal, Action<PosixSignalContext> handler)
{
Token token=new Token(signal, handler);
PosixSignalRegistration result=new PosixSignalRegistration(token);
lock (s_registrations)
{
if (s_registrations.Count==0 && !Interop.Kernel32.SetConsoleCtrlHandler((delegate* unmanaged<int, Interop.BOOL>)(delegate*<int, Interop.BOOL>)(&HandlerRoutine), Add: true))
{
throw Win32Marshal.GetExceptionForLastWin32Error();
}
s_registrations.Add(token);
return result;
}
}
從卦中看 handler 是通過 Kernel32.SetConsoleCtrlHandler 方法進行了注冊，不相信的話也可以用 windbg 驗證一下。
0:000> bp KERNEL32!SetConsoleCtrlHandler
breakpoint 0 redefined
0:000> g
0:000> k 6
# Child-SP RetAddr Call Site
00 00000064`e7b7e948 00007ff9`8162b797 KERNEL32!SetConsoleCtrlHandler
01 00000064`e7b7e950 00007ff9`817ac3cd System_Private_CoreLib+0x1ab797
02 00000064`e7b7ea20 00007ff9`817ac270 System_Private_CoreLib!System.Runtime.InteropServices.PosixSignalRegistration.Register+0xdd
03 00000064`e7b7ea90 00007ffa`144f8437 System_Private_CoreLib!System.Runtime.InteropServices.PosixSignalRegistration.Create+0x10
04 00000064`e7b7eac0 00007ff9`226f29a1 System_Console!System.Console.add_CancelKeyPress+0x97
05 00000064`e7b7eb20 00007ff9`8229af33 ConsoleApp1!ConsoleApp1.Program.Main+0x61
...
熟悉Win32編程的朋友相信已經(jīng)很明白了，原來 C# 的 Ctrl+C 就是基于 win32api 封裝的一套玩法，即用KERNEL32!SetConsoleCtrlHandler 來注冊, 用KERNELBASE!CtrlRoutine 來發(fā)布，要想驗證非常簡單，可以在回調(diào)函數(shù)中加一個 Debugger.Break(); 即可。
static void CancelKeyPressHandler(object sender, ConsoleCancelEventArgs e)
{
Console.WriteLine("你按下了 Ctrl+C！");
// 在這里可以添加你希望執(zhí)行的代碼
e.Cancel=true;
Debugger.Break();
}
將程序跑起來后，在控制臺上使用Ctrl+C快捷鍵，這里要注意一點，這個事件會引發(fā)一個中斷，我們用 gn （Go with Exception Not Handled）來處理，否則 windbg 就會把這個異常通知給吞掉。
0:000> g
(224c.51c8): Control-C exception - code 40010005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
KERNELBASE!CtrlRoutine+0x369ff:
00007ffa`4ab9169f 0f1f440000 nop dword ptr [rax+rax]
0:008> dp rax+rax L1
00000456`73806260 ????????`????????
0:008> gn
(224c.51c8): Break instruction exception - code 80000003 (first chance)
KERNELBASE!wil::details::DebugBreak+0x2:
00007ffa`4ab9d962 cc int 3
0:008> k
# Child-SP RetAddr Call Site
00 0000003f`63b7f848 00007ff9`82343ed9 KERNELBASE!wil::details::DebugBreak+0x2
01 0000003f`63b7f850 00007ff9`8184a66a coreclr!DebugDebugger::Break+0x149 [D:\a\_work\1\s\src\coreclr\vm\debugdebugger.cpp @ 148]
02 0000003f`63b7f9d0 00007ff9`227198ca System_Private_CoreLib!System.Diagnostics.Debugger.Break+0xa [/_/src/coreclr/System.Private.CoreLib/src/System/Diagnostics/Debugger.cs @ 18]
03 0000003f`63b7fa00 00007ffa`1448922d ConsoleApp1!ConsoleApp1.Program.CancelKeyPressHandler+0x4a [D:\code\MyApplication\ConsoleApp1\Program.cs @ 32]
04 0000003f`63b7fa30 00007ff9`817ac6c3 System_Console!System.Console.HandlePosixSignal+0x7d [/_/src/libraries/System.Console/src/System/Console.cs @ 952]
05 0000003f`63b7fa80 00007ffa`4ab91704 System_Private_CoreLib!System.Runtime.InteropServices.PosixSignalRegistration.HandlerRoutine+0x193 [/_/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/PosixSignalRegistration.Windows.cs @ 106]
06 0000003f`63b7fb20 00007ffa`4b667614 KERNELBASE!CtrlRoutine+0x36a64
07 0000003f`63b7fc10 00007ffa`4cdc26a1 KERNEL32!BaseThreadInitThunk+0x14
08 0000003f`63b7fc40 00000000`00000000 ntdll!RtlUserThreadStart+0x21
從上面的卦信息來看，果然走了 KERNELBASE!CtrlRoutine 邏輯觸發(fā)了我們的自定義回調(diào)函數(shù)，我相信心細的朋友肯定會有一個疑問？這個線程是怎么 new 出來的，我的代碼中沒有創(chuàng)建呀！
要回答這個問題，需要你對 windows 操作系統(tǒng)中的一些重要進程有一個了解，比如說 csrss.exe 是干什么的，可以咨詢一下 chatgpt。
它的話已經(jīng)含沙射影的告訴我們，線程有可能是 csrss進程 遠程注入的，那是不是這樣呢？可以下斷點觀察。
0: kd> !process 0 0 csrss.exe
PROCESS ffffe001d350f300
SessionId: 0 Cid: 0180 Peb: 7ff755c16000 ParentCid: 0178
DirBase: 1037cd000 ObjectTable: ffffc000a88e0480 HandleCount: <Data Not Accessible>
Image: csrss.exe
PROCESS ffffe001d351c080
SessionId: 1 Cid: 01d8 Peb: 7ff75628d000 ParentCid: 01c8
DirBase: 10471f000 ObjectTable: ffffc000a907a140 HandleCount: <Data Not Accessible>
Image: csrss.exe
0: kd> bp /p ffffe001d351c080 ntdll!NtCreateThreadEx
0: kd> g
3: kd> .reload /user
3: kd> k
# Child-SP RetAddr Call Site
00 000000ff`917ff238 00007fff`9e9d6720 ntdll!NtCreateThreadEx
01 000000ff`917ff240 00007fff`9e9d6602 ntdll!RtlpCreateUserThreadEx+0x110
02 000000ff`917ff380 00007fff`9b310290 ntdll!RtlCreateUserThread+0x62
03 000000ff`917ff3f0 00007fff`9b30efb9 winsrv!InternalCreateCallbackThread+0x114
04 000000ff`917ff4b0 00007fff`9b3109e9 winsrv!CreateCtrlThread+0xe9
05 000000ff`917ff610 00007fff`9b365837 winsrv!SrvEndTask+0xa9
06 000000ff`917ff880 00007fff`9e969f75 CSRSRV!CsrApiRequestThread+0x4d7
07 000000ff`917ffd10 00000000`00000000 ntdll!RtlUserThreadStart+0x45
從卦中的 CreateCtrlThread 和 ntdll!NtCreateThreadEx 來看，貌似真的創(chuàng)建了Ctrl+C相關(guān)的遠程線程，那到底是不是呢，方法簽名如下：
NTSTATUS NtCreateThreadEx(
PHANDLE ThreadHandle,
ACCESS_MASK DesiredAccess,
POBJECT_ATTRIBUTES ObjectAttributes,
HANDLE ProcessHandle,
PVOID StartRoutine,
PVOID Argument,
ULONG CreateFlags,
ULONG_PTR ZeroBits,
SIZE_T StackSize,
SIZE_T MaximumStackSize,
PVOID AttributeList
);
然后用 windbg 提取第五個參數(shù)(StartRoutine) 驗證下即可，截圖如下：
從卦中信息看確實是用 kernelbase!CtrlRoutine 作為線程入口點的，也就得到了驗證。
到這里可能又有朋友提出了一個新的問題，上一篇你不是說 conhost.exe 的 GetMessageW 是用來承接窗口事件的嗎？比如這個 Ctrl+C 事件，那它怎么通知 csrss.exe 給 ConsoleApp1.exe 注入一個遠程線程呢？
這個問題聽起來挺燒腦的，其實熟悉Windows編程的朋友都知道，在Windows內(nèi)核中有一個叫做ALPC的機制專門用來實現(xiàn)進程間通訊，言外之意就是 conhost 和 csrss 有一個 ALPC連接，可以用windbg 的 !alpc 命令觀察。
1: kd> !process 0n4028 0
Searching for Process with Cid==fbc
PROCESS ffffe001d26a3080
SessionId: 1 Cid: 0fbc Peb: 7ff680afc000 ParentCid: 05e4
DirBase: 8b8de000 ObjectTable: ffffc000ab252cc0 HandleCount: <Data Not Accessible>
Image: conhost.exe
1: kd> !alpc /lpp ffffe001d26a3080
Ports the process ffffe001d26a3080 is connected to:
ffffe001d28a25c0 0 -> ffffe001d1749090 ('ApiPort') 1 ffffe001d351c080 ('csrss.exe')
...
1: kd> !process ffffe001d26a3080
...
THREAD ffffe001d2250080 Cid 0fbc.0f94 Teb: 00007ff680afe000 Win32Thread: ffffe001d4559fa0 WAIT: (WrLpcReply) UserMode Non-Alertable
ffffe001d22506b8 Semaphore Limit 0x1
Waiting for reply to ALPC Message ffffc000b1c6a7a0 : queued at port ffffe001d1749090 : owned by process ffffe001d351c080
Not impersonating
DeviceMap ffffc000a9ea6f50
Owning Process ffffe001d26a3080 Image: conhost.exe
Attached Process N/A Image: N/A
Wait Start TickCount 48619 Ticks: 1 (0:00:00:00.015)
Context Switch Count 1406 IdealProcessor: 1
UserTime 00:00:00.031
KernelTime 00:00:00.687
Win32 Start Address 0x00007fff8e601c90
Stack Init ffffd00030df4c90 Current ffffd00030df4500
Base ffffd00030df5000 Limit ffffd00030def000 Call 0000000000000000
Priority 12 BasePriority 8 PriorityDecrement 2 IoPriority 2 PagePriority 5
Child-SP RetAddr Call Site
ffffd000`30df4540 fffff802`792c0090 nt!KiSwapContext+0x76
ffffd000`30df4680 fffff802`792bfaa8 nt!KiSwapThread+0x160
ffffd000`30df4730 fffff802`792b86e5 nt!KiCommitThreadWait+0x148
ffffd000`30df47c0 fffff802`792bc643 nt!KeWaitForSingleObject+0x385
ffffd000`30df4870 fffff802`7969e70b nt!AlpcpSignalAndWait+0x213
ffffd000`30df4910 fffff802`7969f32a nt!AlpcpReceiveSynchronousReply+0x5b
ffffd000`30df4970 fffff802`7978f1fd nt!AlpcpProcessSynchronousRequest+0x34a
ffffd000`30df4a60 fffff802`7978f142 nt!LpcpRequestWaitReplyPort+0x95
ffffd000`30df4ac0 fffff802`793cdb63 nt!NtRequestWaitReplyPort+0x6e
ffffd000`30df4b00 00007fff`9e9f3a4a nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd000`30df4b00)
00000062`3d2bf5d8 00000000`00000000 ntdll!NtRequestWaitReplyPort+0xa
仔細觀察卦中的信息可以看到，確實有一條和 csrss.exe 通信的 ALPC連接，并且 conhost 正在等待 csrss的消息返回，即 Waiting for reply to ALPC Message。
到這里我覺得所有的疑問都打通了，畫一張圖大概就是這個樣子。
這一篇詳細的解讀了 Ctrl+C 的底層玩法，我覺得更重要的是如何用 windbg 眼見為實，這個才是調(diào)試的價值，希望能夠給這個問題有疑惑的朋友帶來一點價值。