从void类型shared_ptr执行别名构造是否会产生未定义行为？

核心结论 #

只要你题目中描述的cast_to_b转换是确实安全的，这段代码完全符合C++标准规范，别名构造本身不会触发任何未定义行为。

判定依据 #

• 首先看C++标准对shared_ptr别名构造函数的明确规定：对于重载template<class Y> shared_ptr(const shared_ptr<Y>& r, element_type* p) noexcept，构造出的新shared_ptr仅与r共享所有权控制块，其get()方法直接返回传入的p指针；当引用计数归0时，销毁的是原r所管理的对象（也就是本场景中的A实例），绝不会对传入的p指针执行delete或其他内存释放操作。
• 标准从未对传入的p指针和原r管理的对象之间的关系做强制约束：既不要求p指向原对象的基类/子类子对象，也不要求p落在原对象的内存范围内。别名构造的设计初衷就是支持持有和原托管对象生命周期绑定的任意指针——比如指向原对象内部成员的指针、指向和原对象同生命周期的外部关联对象的指针，都是合法用法。
• 你个人的判断是对的：这个构造函数的本质就是"借用原shared_ptr的引用计数逻辑，托管一个自定义的指针值"，整个过程不会对p做任何隐式转换、偏移或者合法性校验，自然不会因为指针类型不匹配产生UB。

唯一可能触发UB的边界 #

所有风险都和别名构造本身无关，只和你传入的指针合法性、以及后续使用方式有关：

1. 如果cast_to_b的转换本身是未定义行为（比如直接把void*按不兼容的类型强转、没有先转回原类型A*再做合法的向下转型），那不管是否封装为shared_ptr，这个指针本身的使用就是UB。但你题目中已经说明该转换是编译期代理保证安全的，这层风险就不存在。
2. 如果ptr_b指向的内存生命周期短于sp_b及所有它的拷贝的生命周期，那后续通过sp_b访问悬空指针时会触发UB——但这是无效指针访问的通用规则，和shared_ptr的实现无关。

关于实现差异的澄清 #

不存在所谓的实现定义边界：从C11标准引入该构造函数至今，所有主流标准库实现（GCC libstdc、Clang libc++、MSVC STL）都严格遵循标准语义实现别名构造，没有任何实现会额外检查p和原托管指针的关联性，也不会对p做任何超出标准规定的操作。

一个非常常见的标准库内置用法就是通过别名构造获取指向std::pair内部第二个元素的shared_ptr，示例如下，这和你当前场景的逻辑完全一致，是被广泛使用的合规写法：

std::shared_ptr<std::pair<int, B>> p = std::make_shared<std::pair<int,B>>();
std::shared_ptr<B> pb(p, &p->second); // 完全合规的别名构造用法

内容的提问来源于stack exchange，提问作者JustClaire